Hungarian notation

History

Systems Hungarian vs. Apps Hungarian

• lAccountNum : variable is a long integer ;
• arru8NumberList : variable is an array of unsigned 8-bit integers ;
• bReadLine : function with a byte-value return code.
• strName : Variable represents a string containing the name, but does not specify how that string is implemented.

• rwPosition : variable represents a row ;
• usName : variable represents an unsafe string, which needs to be "sanitized" before it is used
• szName : variable is a zero-terminated string ; this was one of Simonyi's original suggested prefixes.

• pX is a pointer to another type X; this contains very little semantic information.
• d is a prefix meaning difference between two values; for instance, dY might represent a distance along the Y-axis of a graph, while a variable just called y might be an absolute position. This is entirely semantic in nature.
• sz is a null- or zero-terminated string. In C, this contains some semantic information because it is not clear whether a variable of type char* is a pointer to a single character, an array of characters or a zero-terminated string.
• w marks a variable that is a word. This contains essentially no semantic information at all, and would probably be considered Systems Hungarian.
• b marks a byte, which in contrast to w might have semantic information, because in C the only byte-sized data type is the char, so these are sometimes used to hold numeric values. This prefix might clear ambiguity between whether the variable is holding a value that should be treated as a character or a number.

Relation to sigils

Examples

• bBusy : boolean
• chInitial : char
• cApples : count of items
• dwLightYears : double word
• fBusy : flag
• nSize : integer or count
• iSize : integer or index
• fpPrice: floating-point
• dbPi : double
• pFoo : pointer
• rgStudents : array, or range
• szLastName : zero-terminated string
• u16Identifier : unsigned 16-bit integer
• u32Identifier : unsigned 32-bit integer
• stTime : clock time structure
• fnFunction : function name

• pszOwner : pointer to zero-terminated string
• rgfpBalances : array of floating-point values
• aulColors : array of unsigned long

• For programmers who learned Windows programming in C, probably the most memorable examples are the wParam and lParam for the WindowProc function.
• hwndFoo : handle to a window
• lpszBar : long pointer to a zero-terminated string

• g_nWheels : member of a global namespace, integer
• m_nWheels : member of a structure/class, integer
• m_wheels, _wheels : member of a structure/class
• s_wheels : static member of a class
• c_wheels : static member of a function

Advantages

• The symbol type can be seen from its name. This is useful when looking at the code outside an integrated development environment — like on a code review or printout — or when the symbol declaration is in another file from the point of use, such as a function.
• In a language that uses dynamic typing or that is untyped, the decorations that refer to types cease to be redundant. In such languages variables are typically not declared as holding a particular type of data, so the only clue as to what operations can be done on it are hints given by the programmer, such as a variable naming scheme, documentation and comments. As mentioned above, Hungarian Notation expanded in such a language.
• The formatting of variable names may simplify some aspects of code refactoring.
• Multiple variables with similar semantics can be used in a block of code: dwWidth, iWidth, fWidth, dWidth.
• Variable names can be easy to remember from knowing just their types.
• It leads to more consistent variable names.
• Inappropriate type casting and operations using incompatible types can be detected easily while reading code.
• In complex programs with lots of global objects, having a basic prefix notation can ease the work of finding the component inside of the editor. For example, searching for the string btn might find all the Button objects.
• Applying Hungarian notation in a narrower way, such as applying only for member variables, helps avoid naming collision.
• Printed code is more clear to the reader in case of datatypes, type conversions, assignments, truncations, etc.

  Disadvantages

• The Hungarian notation is redundant when type-checking is done by the compiler. Compilers for languages providing strict type-checking, such as Pascal, ensure the usage of a variable is consistent with its type automatically; checks by eye are redundant and subject to human error.
• Most modern integrated development environments display variable types on demand, and automatically flag operations which use incompatible types, making the notation largely obsolete.
• Hungarian Notation becomes confusing when it is used to represent several properties, as in a_crszkvc30LastNameCol: a constant reference argument, holding the contents of a database column LastName of type varchar which is part of the table's primary key.
• It may lead to inconsistency when code is modified or ported. If a variable's type is changed, either the decoration on the name of the variable will be inconsistent with the new type, or the variable's name must be changed. A particularly well known example is the standard WPARAM type, and the accompanying wParam formal parameter in many Windows system function declarations. The 'w' stands for 'word', where 'word' is the native word size of the platform's hardware architecture. It was originally a 16 bit type on 16-bit word architectures, but was changed to a 32-bit on 32-bit word architectures, or 64-bit type on 64-bit word architectures in later versions of the operating system while retaining its original name. The semantic impedance, and hence programmer confusion and inconsistency from platform-to-platform, is on the assumption that 'w' stands for a two byte, 16-bit word in those different environments.
• Most of the time, knowing the use of a variable implies knowing its type. Furthermore, if the usage of a variable is not known, it cannot be deduced from its type.
• Hungarian notation reduces the benefits of using code editors that support completion on variable names, for the programmer has to input the type specifier first, which is more likely to collide with other variables than when using other naming schemes.
• It makes code less readable, by obfuscating the purpose of the variable with type and scoping prefixes.
• The additional type information can insufficiently replace more descriptive names. E.g. sDatabase does not tell the reader what it is. databaseName might be a more descriptive name.
• When names are sufficiently descriptive, the additional type information can be redundant. E.g. firstName is most likely a string. So naming it sFirstName only adds clutter to the code.
• It's harder to remember the names.
• Multiple variables with different semantics can be used in a block of code with similar names: dwTmp, iTmp, fTmp, dTmp.
• Placing data type or intent character identifiers as a prefix to the field or variable's Given name subverts the ability, in some programming environments, to jump to a field or variable name, alphabetically, when the user begins typing the name. FileMaker, for example, is one such programming environment. It may be preferable when using one of these programming environments to instead suffix Given names with such identifying characters.

  Notable opinions

• Robert Cecil Martin :

  ... nowadays HN and other forms of type encoding are simply impediments. They make it harder to change the name or type of a variable, function, member or class. They make it harder to read the code. And they create the possibility that the encoding system will mislead the reader.

• Linus Torvalds :

  Encoding the type of a function into the name is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.

• Steve McConnell :

  Although the Hungarian naming convention is no longer in widespread use, the basic idea of standardizing on terse, precise abbreviations continues to have value. Standardized prefixes allow you to check types accurately when you're using abstract data types that your compiler can't necessarily check.

• Bjarne Stroustrup :

  No I don't recommend 'Hungarian'. I regard 'Hungarian' as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments. In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.

• Joel Spolsky :

  If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant unsafe string and s meant safe string. They're both of type string. The compiler won't help you if you assign one to the other and Intellisense won't tell you :wikt:bupkis#English|bupkis. But they are semantically different. They need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky. There's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug and maintain, and, most importantly, it makes wrong code look wrong.... was a subtle but complete misunderstanding of Simonyi’s intention and practice.

• Microsoft's Design Guidelines discourage developers from using Systems Hungarian notation when they choose names for the elements in.NET class libraries, although it was common on prior Microsoft development platforms like Visual Basic 6 and earlier. These Design Guidelines are silent on the naming conventions for local variables inside functions.