Hungarian in .NET: ASP Alliance

Print Add To Favorites Email To Friend Rate This Article
Hungarian in .NET

page 1 of 3

Published: 06 Oct 2003

Unedited - Community Contributed

Abstract
A discussion of the pros and cons of using Hungarian Notation in the .NET development environment.

by J. Ambrose Little
Feedback

Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 27971/ 43

Article Contents:

Exposition

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.

View Entire Article

(Page 2) »

User Comments

Title: Useful
Name: Ushanka
Date: 2007-04-13 5:51:10 AM
Comment:
Pretty useful information for me. I wish I found this article earlyer.

Title: Here we go again!
Name: Silas2
Date: 2006-12-19 8:59:19 AM
Comment:
I remember reading a Microsoft publication which said all variables should be Variants (where did that go?) and so no variable declarations should have any prefix...maybe this is just such a passing fad.
I definately find HN easier to read, but I didn't see any reference to the other big prefix - scope. If find it much clearer to instantly see where a variable has been declared by looking at the name than Shift-F2ing all day long.

Title: MHO
Name: one
Date: 2006-11-15 9:49:02 AM
Comment:
Just a quick comment. I fully agree with the ppl that said they want to have their txtBoxes and lbl's all grouped in IntelliSense. I do not believe in prefixing every variable with a meaningful set of characters, intA, intB and so on gets old after a while. I'd still use HN on visual elements like labels, buttons and so on.

To those that claim it's easy to take the mouse and hover over the damned variable, i'd have to say: no. It's easy, granted, but try doing that for every damned button, textbox and label in a 70 label+textbox form that share the name (i've had those) to see if it's a label or not. The solution would be to use naming conventions that specify the type, like "FirstNameLabel". I'd still go with lblFirstName - easier to recognize without reading the whole word.
You have to agree, this does seem natural of MS - make it easy enough to be ..read..as..text... Who does that? Do you read code just for fun? Or do you want to be efficient and quick? If i have to write Label after each object of the said kind, is it more efficient than 'lbl' ? The IDE is great but i'm not waiting for some tooltip to see what my object is.
Bottom line: we don't use (at the firm) HN for variables and such, we won't be using it for anything anymore (all hail MS - their will be done) but I will still use it in visual objects in my private projects - it makes more sense. Peace!

Title: RoyValdz Notation
Name: royvaldz
Date: 2006-10-29 10:51:44 AM
Comment:
RoyValdz Notation
I believe the way to go is carry on the Hungarian Notation spirit but apply the practicality of the MS recommended .NET notation. I'm used to programming in Powerbuilder so I hate to let go of the Hungarian Notation. But there's a reason of course why novel ideas are there. To name a variable for example we dont have to prefix it with a type abbreviation when its type seems obvious. But in case when it can lead to confusion like the variable name Code which can be in "real life" required to be numeric (to compute checksum) or alphanumeric (merely for identifier) then numCode or charCode should be appropriate. Why not CreditCardNumber or ItemCode? If you are making a reusable code to validate security numbers for DIFFERENT purposes using the name CreditCardNumber can be misleading. Otherwise CreditCardNumber is enough. Why not NumericCode or CharacterCode? If a programmer finds himself having to use NumericCode or CharacterCode frequently it would be tedious. Besides to use num for Numeric and char for Character doesnt hurt especially if these mnemonics are generally known unless it's your Sales Manager who's reading. Moreover the Camel Case helps by hinting that the first name part clarifies the next part. While names like Birthdate is more natural than dateBirth this does not mean you can't intentionally use names like dateReported, intMonthReported (month as number) or charMonthReported (month as fullname).

In other words use Hungarian Notation when it helps clarify your variable name but not when there's a natural name around. Final analysis Hungarian Notation should now serve as convenience to the programmer instead of as a must, and that the .NET notation should replace the former to avoid cryptic names.

Title: Who cares
Name: Talorthain
Date: 2006-04-14 9:16:22 AM
Comment:
I print out code and back it up, after computer power supply blew up and took a load of work with it. But on the comments about HNotation, who cares. Use what you feel comfortable with. I use HNotation but not in the complete form. I have taken the bits I feel help and discarded the rest.

Title: Can't Move Me! Part 2
Name: BLong
Date: 2006-01-04 1:39:45 PM
Comment:
My post was cut off...here's the remainder:

[There are too many different types to create meaningful, unique abbreviations for, particularly in an object-oriented system. ]
--The set of value types is fairly static and prefixes used for them are somewhat standardized - for instance, someone reading code will quickly and easily determine the prefix being used for each type (s or str, i or int, etc). Objects should be prefixed with 'obj' or something similar.

[Abbreviation systems vary from company to company and even from person to person—it adds an unnecessary learning curve.]
--The learning curve shouldn't be any longer than a few seconds. One can find a few declarations if the prefixes being used are not clear.

[Never applied consistently, even by Microsoft.]
--Just because something is not applied consistently doesn't make it a bad thing - no matter who is inconsistent with it. Application of laws within our nation is inconsistent sometimes even within the same jurisdiction, but it doesn't justify the abandonment of law.

Title: Can't Move Me!
Name: BLong
Date: 2006-01-04 1:38:02 PM
Comment:
Kevin,

I agree with your comments. The bottom line is that abandoning Hungarian notation (or some notion of type and scope prefixing) produces code that is less readable. Period.

Ambrose, I appreciate your research into the matter. To most readers, you've put together a good synopsis and supported it well (albeit mainly via arbitrary statements from Microsoft).

As a final note, I want to address the Cons presented as well:

[If you change an identifier’s type, you must change the identifier itself and all references to it. ]
-- Use "Search/Replace" (ctrl-h).

[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. ]
--If you're reading the code, it's probably because you want to understand what it's doing. Reading code with an ignorance of types rarely yields understanding - I can't remember ever reading non-prefixed code without having to scroll around and look for declarations.

[Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names (such as “sdr” for SqlDataReader).]
--Poor variable names is a completely separate issue. For instance, abandoning prefixes doesn't keep someone from defining an integer called X, which is an even poorer name than intX - with the prefix, at least you know at a glance that the variable is an int.

[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? ]
--I have to grant that this can be an issue. However, if a developer is paying explicit attention to types (by virtue of prefixing), it is likely that he is careful to rename variables if/when a change of type is necessitated.

[There are too many different types to create meaningful, unique abbreviations for, par

Title: Ugh. Hungarian makes so much more sense!
Name: Kevin L. Kitchens
Date: 2005-11-22 12:17:12 AM
Comment:
Sad that Microsoft arbitrarily decided to drop the logical use of Hungarian notation. I've yet to see ANY solid reasons as to why the more confusing camel case (without a Hungarian prefix) is used.

I was against HN when I first started coding, but then the common sense of it set in and I wholly endorsed it. Obviously people don't use it for class properties or exposed methods, but for variable naming, there is nothing better -- especially not this silly non-standard MS is advocating.

Of course, I never got into the extraneous strName and intNumber form, preferring the better sName and iNumber format, leaving most three character prefixes for txtBoxes and cmdButtons.

The good thing about HN is that no matter what standard was used, it wouldn't take long for a developer to get up to speed. Most places would use s (or the wasteful str) for string, l for long, i for integer, etc. The more exotic types may differ from place to place, but there will NEVER be a standard that everyone can agree on -- except MS's abandon-a-standard they recommend now.

Title: HTML
Name: J. Ambrose Little
Date: 2005-09-27 6:54:02 AM
Comment:
It's pronounced like it looks: hotmail. :)

No, really, it's haych tee em elle, if your British; otherwise, it's aych tee em elle.

Title: Acronym
Name: Phil
Date: 2005-09-27 5:07:54 AM
Comment:
>>When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or HTMLButton

"HTML" is an acronym ? How is it pronounced ?

Title: Mr
Name: IMH
Date: 2005-08-30 9:40:19 AM
Comment:
Happy, I don't think it's necessary to poke fun at someone for printing their sourcecode. I have done it before now (indeed I was taught to in the general course of debugging as is) and it's likely I'll end up doing it again at some stage, that said, it's rare I get a bug of that nature and it's usually in assembler anyway.

So disappointing has a point (albeit presented like a smart arse) but I think ultimately printing of source code isn't something I've done in the course of programming so much lately; I guess with the advent of full screens of code, smaller fonts and biggers screen in terms of res and inches; less need to print things.

I am however all for keeping some semblence of types alive in there especially where controls are concerned. Maybe this is all that's needed?

Title: Faster intellisense
Name: chubb
Date: 2005-08-17 6:50:58 PM
Comment:
Using hungarian helps you navigate intellisense. If I am in a code behind page and I want to quickly popup my TextBoxes that exist in my aspx page, I type in "tb" and behold my textboxes appear. But of course, I would never use it in an exposed property or db field.

Title: Best Practices Guidelines
Name: Scott Miller
Date: 2005-04-15 3:58:34 PM
Comment:
In Practical Guidelines and Best Practices for Visual Basic and Visual C# Developers (2005, MS Press), it says that Hungarian notation should be replaced by pascal casing in VB and camel casing in C#, along with descriptive variable names. Hungarian notation has problems in Intellisense, not the least of which would be the long list of intX and strX named variables.

Title: Happy
Name: J. Ambrose Little
Date: 2005-01-28 11:51:01 AM
Comment:
Dear Disappointed,

I agree that if you print out your source code (you really do that?), then Intellisense doesn't work at all. In that instance you'll have to rely on Intelligence, which is something you might want to consider looking into. (j/k)

As for Microsoft, I don't abandon things just cuz they say so either, but a lot of folks put a lot of weight into what MS says, so it helps to support the argument for those kinds of people.

Thanks for commenting.

Title: Disappointing
Name: snyderm
Date: 2005-01-28 11:43:54 AM
Comment:
I'm having a problem with something. When I print my source code and hold my finger over the variable name, Intellisense doesn't pop up and tell me the data type.

This is the main argument for continuing to use Hungarian notation, imo.

If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either.