Hungarian Notation - The Good, The Bad and The Ugly

Related Sites

The advantage of Hungarian notation is a reminder of the type of a variable.

In a true and pure OO language (which C++ is not) Hungarian notation would have no purpose. Here, variables are typeless - they contain an object, the type of which depends on the object itself, not the variable. There are no primitive types.

However, C++ is a hybrid language. [...] You can mix objects with primitive data-types etc.

Hungarian notation (or a variation of this) has its place in C++ when referring to data that really DOES have a particular type, by its very nature. eg. Handles can have a 'h' prefix (eg hWnd) - this is simply a shorthand convention that save writing something like 'handle_of_Window'. Similarly 'nLines' is short for 'number_of_lines', 'bOpen' is short for 'is_open', 'pData' is short for 'pointer_to_data'. As a convenient (and hopefully consistently used) shorthand, such a notation can save on extra typing - and less typing can mean less typing mistakes and more compact (but just as readable) code.

However, like all things, it should be used consistently and appropriately.

Hungarian Notations's disadvantage can be when the name does NOT match the type. eg. you originally had a single byte for a value, but the specs change and now you need an unsigned long - that means not only must you change the type of the declaration - in one place - but the name of the variable everywhere it is used.

Also, in C++, what is often more important to know about a variable is not its type, but its scope (local, function arg, file static, member, static member, global etc). This can be easily encoded with a Hungarian-style notation, such as what MFC uses, with m_ for member, c_ for static members etc.

[... Hungarian notation will] prevent your code from being ported from 16 bit to 32 bit platforms. It helps prevent any accidental abstraction from creeping in. :-)

If you have a type for a host variable, the proper way to name it is to use something like HostID. Then anyone can declare a variable to be of type HostID and use its operations without knowing or caring if it is a class, a structure, an integer, etc. This is called encapsulation and is a sign of good programming. It is one of the basic concepts of Object Oriented Programming. Notice that the HostID can be of any type and you don't care or want to know what type it is. You only need to know that it is the type required for a parameter to a function or what operations are available on the type.

[...]

This is one of the reasons why there are types in the ANSI C standard for size_t, pointer differences, etc. Notice that those names do not use Hungarian.

Robert C. Martin wrote about the ugly:

Hungarian notation encodes type information into variable names. This is very useful in languages that don't keep track of types information for you. But in C++ or Eiffel it is completely redundant. Thus, the notation simply adds to obscurity.

Hungarian notation is, when all is said and done, a commenting technique. And the one great law of comments is that they lie. Comments are not syntax checked, there is nothing forcing them to be accurate. And so, as the code undergoes change during schedule crunches, the comments become less and less accurate.

The same happens with hungarian notation. When the type of a variable changes, it is not likely that you are going to hunt through all the code and change all occurrences of its name. Especially during the schedule crunch. Thus, the variables name will become a lie.

[For an example of this, look at the documentation for wParam in Microsoft Windows 32-bit: It changed from a 16-bit value (w stands for word) to a 32-bit value (which should have been dwParam). -YS]

Charles Simonyi, Program Identifier Naming Conventions

Microsoft Naming Conventions for Visual Basic
(I counted 138(!) different prefixes specified in this document)

Michael Quinion, Gobbledygook in C
(Explains the origin of the name "hungarian notation")

Greg Legowski, A Guide to Hungarian Notation