Hungarian Notation

One of the many improvements, I believe, that the .NET Framework introduced to Windows programming was the eradication of Hungarian notation.

Hungarian notation is the practice of including an abbreviated prefix in front of a variable name to indicate both its type and usually its function. One of the benefits that Joel mentions in his recent article “Make Wrong Code Look Wrong”  is its ability to let the programmer readily locate errors. He points to examples in both Excel and Word.

As Gregg responds to Joel that it is better to use the type system rather than variable prefixes to detect wrong code. Wrong code would thus be detected by the compiler, which is better at this process than human beings. It is no coincidence that Hungarian naturally arose in a C-based environment, which lacked strong type-checking.

Here are what I may be some plausible advantages of Hungarian notation:

• Making wrong code look wrong. Making it obvious when two variables of different functions are incorrectly exchanged
  
• Succinct representation of variable names.
  
• Consistency. Hungarian is a well-documented, consistent scheme for naming variables. Though, in actuality, it really isn’t all that consistent with some groups using, for example, b or f  for boolean types, v or g for global variables, and so on.
  
• Name reuse. The same name can be reused for different variables by incorporating a different prefix. Often there aren’t as many relevant words in English as there are variables names, so its a simple matter to reuse the same name with a different prefix.

As Joel himself noted in the difference between Application and Systems Hungarian, some of the benefits are not actually realized in practice. For instance, Systems Hungarian, used in the Windows API, simply precedes a variable name with what amounts to abbreviation of the type name without any regard for the variables function.

The problem is that these advantages are not really unique to Hungarian notation but Hungarian has a number of other disadvantages:

• Poor accessibility to other programmers and novices, especially in a platform API which is to be used across many languages by a range of different developers. This is typical of many professions like medicine and law, which invent terms using foreign words, thereby increasing barriers of entry into field to preserve a high level of income for those within.
  
  When I came aboard in Excel, I was already familiar with Windows programming and Hungarian notation (although the vast majority of my programming have previously been in the Macintosh and UNIX environments). Even with my prior background, I was shocked by the profuse and indecipherable Hungarian, which greatly slowed the learning process of understanding the Excel codebase. It was essentially like learning another language.
  
• Encouragement of poor naming practices such as non-descriptive names. Hungarian encourages bad naming practices. For example, almost every variable and structure names, even the long ones, were abbreviated and contained no vowels. I had to put up with nasty beasts like “hprghpplsxclh.” One of my legacies in Excel was to introduce descriptive structure names. It is fairly annoying to regularly encounter types with non-descriptive names and to wonder what their functions are without using an indexing facility.
  
  In their software, Apple has always used long, descriptive names in function calls—made up of real English words, all PascalCased. Microsoft has recently adopted the same convention in .NET (actually, VBA object model was there first, although with less consistency) and enforces them through FXCop, which is a style-policing tool.

 

Comments

[Don Demsak]

Hungarian Notation was a necessary evil when we didn't have intellisense. Now that intellisense is mainstream, no reason for HN.

[anon]

"understanding the Excel codebase. It was essentially like learning another language. " : but isn't any codebase essentially a new language?

[Skarsnik]

You make 'barriers to entry' sound like a bad thing?!?!

If I see another ex-electrician's code in this decade I'm going to go postal I swear.