The original Hungarian notation is due to Charles Simonyi who invented it sometimes while he was working at Xerox Palo Alto Research Center—the Xerox PARC that gave us the mouse and the first graphical user interfaces. The basic principle of Hungarian naming convention is to prefix the variables with one or many particles, encoding alternatively its type or its intend. This lets programmer write prgszNames as a variable name, which is perfectly legible to one well versed in Hungarian; however, but looks mostly like gibberish to just anyone else.
I recently changed my mind about the Hungarian naming convention. I don’t think it’s that stupid anymore.
First, let me explain the two main flavors of Hungarian notation. The first flavor, the System Hungarian, encodes variable types in prefixes. For example, one could have pThing, which encodes a pointer to a Thing, whatever that may be in that program. In System Hungarian one finds a rather large number of prefixes, mostly ambiguous as no one agrees on a canonical notation, which encodes a variety of data types: u for unsigned, l for long, p for pointer, ch for char, c for const, sz for null-terminated string, etc. From the previous list, you understand that lpcszName is a long pointer to a constant null terminated string. While long pointers are somewhat archaic, the type of the variable is unambiguous (provided we all agree on prefixes). The goal of System Hungarian notation is, therefore, to help the programmer treat the variables (or types) thus defined with proper data types and reduce errors due to automagic type-casting that so easily happens with languages like C and C++.
The second variant, Applications Hungarian, or Apps Hungarian, focuses more on encoding intend in the variable name. In Apps Hungarian, one may find rwCurrent, with rw standing for row, maybe for “right word”. One could also find a thing like uvID, for “unverified ID” to hint that this variable holds an ID (type unspecified) that was not verified yet.
While Systems Hungarian makes sense in certain cases—especially APIs that expose complex data types through PODs—Apps Hungarian can be completely and advantageously replaced by smarter variable names. For example, uvID can be replaced by pszUnverifiedID which specifies the variable type (given it’s a simple basic type) and makes the intend perfectly clear while uvID may likely leave the reader in doubt (ultraviolet ID? wassat?)
While I would certain not advocate the integral application of System Hungarian to every variable in a program (certainly not to very localized variables defined within a very restricted scope), I would recommend use of moderate System Hungarian for data exposed by non-standard APIs, especially in public PODs. It’s not because a programmer can include a header and use struct thing that he knows or understands the types involved in the thing; using structure field names such as pclReturnValue makes sures that the programmer knows the intend and the data type.
With object-oriented programming, however, the need for Hungarian-style notation may be lessened by (correct) encapsulation. Encapsulation prevents data members from being exposed directly and, in general, it is possible to implement stronger type checking. For example, the STL makes extensive use of namespaces and classes to ensure correct typing of objects. In many ways, it is much better to use std::ios_base::iostate than something like usFlags (unsigned short) that may vary from one system to the other. Moreover, encapsulation will force you to use accessors which keeps you from accessing directly the real data member, and in this case, it is more or less relevant to the class’ user whether the internal data member is just flags or iostate_flags (I would still use the latter, though).
Charles Simonyi’s original memo