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.
The following are from Microsoft’s guidelines for field names:
The following are from Microsoft’s guidelines for parameter names:
The following is from Microsoft’s guidelines for property names:
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: