Originally Published: 30 September 2002

Recently, my company decided that we need to start working on some standards for .NET development. As I was the one who suggested it, I was the one who was nominated to come up with a proposal to submit to the development group. After some research, and a bit of thinking, I came up with a proposal that included one very controversial suggestion—the near complete abandonment of Hungarian Notation.

As I said, I had done a bit a research, particularly into generic naming guidelines and Microsoft’s guidelines for class library development, as well as examining to some extent the IBuySpy portal’s code. All of this led me to conclude that leaving off from the usage of Hungarian Notation was the way to go, not only for class library development, but for all .NET development, with the compromise that it could be used for local, so-called “temporary” variables if the developer so chooses.

In order to avoid begging the question, I will also say that there are times when the best way to differentiate two objects is through providing some info as to its type. By this I do not mean the object’s type’s type identifier, which is really just an arbitrary specification by the type creator, but rather the object’s type in the real world.

Take for example the identifier "firstName." Observe that "Name" is not just some arbitrary, mutable code construct's identifier but a real-world construct that this particular type member is being used to reflect. We cannot change the type of the real-world construct. At most, we could change the symbol (word) by which we identify that construct, but the construct itself--what it IS--would not change. Of course, changing the symbol we use to identify that construct would indeed require a change in the code identifier, but that would be tantamount to changing our language, which is, suffice it to say, not likely to happen, at least not for the life of the typical program.

In any event, the point is not to argue against using qualifiers and descriptors in our identifiers. On the contrary, we should use meaningful descriptors in our identifier names. What we should not do is limit ourselves to using descriptors that align with arbitrary, code-centric names (type names), and more so, we should not use cryptic, abbreviated prefixes that are based upon said type names for our identifiers.

It will happen, of course, that some type names will align with the meaningful descriptors that we choose for a particular object (as in the case of "Label" in .NET), but such an alignment should be, as far as the consumer of the type is concerned, coincidental. That is, the consumer of a type should create meaningful identifiers based upon the real-world object (and its purpose and qualifiers) that he or she is intending to refer to, regardless of the identifier given to the type itself by the type's creator.

The bottom line is that inasmuch as the name of an identifier, be it for a type or a type member, reflects its real-world construct, it is a good identifier, regardless of whether or not the name happens to include the name of a code construct as well. Hungarian Notation violates this principle by locking the programmer into the use of arbitrary type names and obscuring the real-world type through the use of arbitrary abbreviations.

Below is some material that I compiled in an bulleted-style format to support the assertion that Hungarian Notation should be abandoned in .NET programming.

Pros:

1. Nearly instant recognition of identifier type, assuming familiarity with abbreviations used.
2. Easily distinguish between two or more identifiers of different types used to reference the same conceptual entity.

Cons:

1. If you change an identifier’s type, you must change the identifier itself and all references to it.
2. It obfuscates code from being read like text and thrusts this property of the object forward even if you didn't care about it as the reader.
3. Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names (such as “sdr” for SqlDataReader).
4. It is a human-maintained convention that can be erroneous, thereby misleading code readers even more than they might have been if it weren’t there. Should you check every notational assertion with its declaration anyway? If so, then what is the point of this notation?
5. There are too many different types to create meaningful, unique abbreviations for, particularly in an object-oriented system.
6. Abbreviation systems vary from company to company and even from person to person—it adds an unnecessary learning curve.
7. Never applied consistently, even by Microsoft.

1. In object-oriented programming, it is rarely necessary as code is modularized enough so that the declaration is often visible or easily found if there is a question as to an identifier’s type.
2. The VS.NET IDE offers several ways to quickly identify an object’s type:
   
   • Tooltip; seen by “mousing over” the identifier.
   • Intellisense tells you the type.
   • Type information is provided in the debugger.
3. You can find the object more quickly in Intellisense when it has no type prefix.
4. You can often tell an identifier’s type by the usage. This is particularly true in OO environments where you often set an identifier to a “new” followed by the type or when a method tells you what type it returns, such as GetXmlReader() or LoadControl().
5. Microsoft recommends against it (see the following).

The following are from Microsoft’s guidelines for field names:

• Spell out all words used in a field name. Use abbreviations only if developers generally understand them. Do not use uppercase letters for field names.
• Do not use Hungarian notation for field names. Good names describe semantics, not type.
• Do not apply a prefix to field names or static field names. Specifically, do not apply a prefix to a field name to distinguish between static and non-static fields. For example, applying a g_ or s_ prefix is incorrect.

The following are from Microsoft’s guidelines for parameter names:

• Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.
• Do not prefix parameter names with Hungarian type notation.

The following is from Microsoft’s guidelines for property names:

• Do not use Hungarian notation.

Abbreviations (related to Hungarian Notation; from Microsoft’s guidelines)

To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations:

• Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
• Do not use acronyms that are not generally accepted in the computing field.
• Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
• When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or HTMLButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
• Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use Camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.