Hungarian Notation Lite®
Since bitching (or otherwise) about Hungarian notation appears to be a common past-time right now, I thought I'd shove my oar in and deliver my 2 cents.
If you're trying to write code that looks clean, is readable, and yet conveys that little bit of information that you might need to make your day go by that little bit smoother, just exactly what are you going to do? I mean, without vowing to discard all vowels from your variable names?
Personally, I have some simple rules.
Interfaces start with I
Classes start with C (ok, so I break this one quite a lot...)
Member variables are always prefixed with m_
Flags start with a b for boolean
Pointers to anything start with a p.
Template class hierarchy mixin classes (aka Policy classes) all end in Impl. (That one comes from ATL's CWindowImpl... I just cribbed it).
Generic Template classes (eg. containers) tend to end in T. But this isn't a hard and fast rule.
Dialog classes end in Dlg.
That's about as far as I go usually. I gives you enough information not to make the most basic of mistakes, without tying you down to a framework or system which gets hairy if your code changes a lot or you do some refactoring.
It's funny. The more I think about this, the more I'm certain that it doesn't really matter what you do, as long as you do it with a modicum of consistency. Well, that and remembering that if you get hit by a bus tomorrow, there will be someone going through your code line by line shaking their head in confusion if you get too obtuse.
Edit:
I forgot a couple:
g_ - indicates a global variable. Sometimes I waver between going as far as saying You Must Type global_ instead of g_, but it depends on the project. (For example, embedded software engineers hate me if I try to enforce the long form of this one).
s_ - indicates a static variable.
str - prefix for a string - both a C++ STL string and a C style pointer-to-zero-terminated string.
c - prefix for something that is const.
Simon Cooke is an occasional video game developer, ex-freelance journalist, screenwriter, film-maker, musician, and software engineer in Seattle, WA.
The views posted on this blog are his and his alone, and have no relation to anything he's working on, his employer, or anything else and are not an official statement of any kind by them (and barely even one by him most of the time).