Hungarian Notation Considered Harmful

Scope

Most people agree that scope is an interesting information to include as part of the variable name. Most coding standards use something like m_ for class members, g_ for globals or s_ for statics. Some languages even enforce this as part of the language. In Ruby instance variables start with @, class variables with @@, globals with $, etc.

Type

The most widespread use of hungarian tries to encode the type of a variable in its name. As an example fBlue might mean a boolean flag, iCount an integer, hwndParent a handle to a window, hdcMemory a handle to a device context, lbxCustomers a listbox, etc. This is somewhat analogous to the the variable names that you use in Smalltalk (aDictionary, aCollection). This analogy makes me think that this particular type of hungarian might make sense in the context were it was invented.

Windows Handles

When I started programming on Windows 3.0, MS people used something they called handles. A handle is somewhat similar to a file descriptor in the sense that it allows to access some operating system resource through a standard set of functions. You had window handles, device context handles, brush handles, region handles, and a lot more. In the C header files that shiped with the windows sdk, each handle was typedefed to int. This meant you could pass a handle to a device context to a function expecting an handle to a window and the compiler would happily accept it (not the compilers fault). I remember ReleaseDC being particularly infamous. It took a window handle and a device context handle. I could never remember the order of those params, and getting them wrong meant a GPF [1]. That was nice because it was easy to notice. Most of the times it also meant I had to reboot the computer. Later (win 3.1?) the windows sdk came with a #define STRICT feature. If you used it, handles were declared as pointers to a dummy struct that was different for each handle. This allowed stronger type checking from the compiler and, in my opinion, made hungarian redundant for Windows C/C++ programming.

Visual Basic

Being a MS invention, hungarian was readily taken over by the VB camp. Curiously enough, the first big example I found of hungarian being a bad idea, was while doing some VB programming work (don't ask please!!). The coding guidelines mentioned using something like lb for listboxes, cb for comboboxes and db for drop down combos. I used this conventions and coded some 30 VB forms using it. I used list boxes for all of them. At some point, the customer said he liked combo boxes more. No problem Ernesto will change it in no time... I was confident because I knew that the operations on a list box and on a combo box a mostly the same. Only the visual appearance changes. Enter hungarian and over 50 combo boxes that have to be renamed and some 20 perfectly generic functions whose parameters had to be renamed from lbxFoo to cbxFoo. This time I did the right thing: no hungarian this time. This saved myself a lot of time when the customer decided a tree would represent it better than our old-fashioned combos...

Deja Vu

Back to C++. Recently I was working on some const-correctness issues and to that end I wanted to change a local variable from iterator to const iterator. Easy enough. Yeah, but we were using a version of hungarian, so now the name was wrong: const iterators have a different hungarian prefix. Should I do a search and replace in the function? Will I bother if I have a release in two hours? Isn't this burying ourselves in red tape?

Conclusion

Hungarian notation encodes type information into the name of a variable so that programmers can visually check the correctness of the type.

Don't do it. It makes refactoring more difficult and there are two good alternatives:

If you're using static type checking, let the compiler do the work. See the STRICT discussion above for a way that Microsoft themselves used.
Let your automatic unit tests check the correctness of the program.

If it's that bad, why is it so popular?

Microsoft used to use it a lot.
A very good book (also from MS) says it is a good thing. I know some people who take this book as gospel, including the hungarian part, which is actually the worst part of a otherwise good book. The book is "Writing Solid Code" by Steve Maguire. See this ACCU review for the opinion of somebody who doesn't like it at all.