My favorite feature is one that carried over from Vista: The Quick Search/Launch Box. I used to just have hotkeys for a bunch of random things but decided that typing out their executable names was more memorable. Windows key followed by "calc" is something I sometimes need but not frequently enough to warrant a hotkey for. Someday I'd like to learn the Control Panel executable names so I don't have to dig around there. Specific to 7, I'm glad the Windows + # keys work on the taskbar just like they did to the Quick Launch bar in Vista.

I can read camelCase more easily than underscores. Mainly because I've seen much more camelCase code. The extra benefit is that I have shorter lines because of shorter variable names. I try to keep within 80 characters of width per line because I hate scrolling horizontally. Doing underscores feels unusual because I'm not used to holding Shift and hitting any key outside of the character keys.

Philip Laureano wrote:

What's the most diplomatic way to tell them that their code well...sucks?

I suggest not even trying. Cultural ideals are embedded into them when they grow up and will be hell to break. Any suggestions you give have the possibility of being seen as heretical or critical. Rather, see if you can work around their "flawed outlook". But I understand that your job would be to tell them where stuff isn't working well. So do it as sparingly as you can. Try ordering the possible problems in the code in terms of how lethal and commonly encountered they are. Then confront them one-on-one with the biggest and baddest things first. If they have multiple issues, see if you could postpone telling them about the others things for later. Pointing out too many things may give them the feeling they are incompetent or that you are cruel. The hardest part is lessening the blow of your bad news. Don't be direct in pointing out problems; perhaps you could ask them a question that leads them towards the flaw (ex: "What if the variable was assigned this value?"). Be as discreet as possible; don't let the co-workers know or even get the hint that the person you talked to was "scolded". The person you talk to will be nervous if anyone else knew that you gave him/her advice. Lastly, see if you can resolve the coding problem in terms that even the coder would prefer. The culture is oriented towards everyone as a whole, right? So it would also be better in their eyes if the final product was more user-friendly and/or syntactically understandable (for fellow readers). While you may not like the idea (I know I wouldn't), I suggest letting all code that works slide by regardless of how poorly it was constructed. There's a good chance that they'll code that way for the rest of their life.