Hungarian in .NET
page 3 of 3
by J. Ambrose Little
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 31299/ 31

Reasons Why Not to Use Hungarian Notation
  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.

View Entire Article

User Comments

Title: Useful   
Name: Ushanka
Date: 2007-04-13 5:51:10 AM
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
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
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 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
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
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
My post was cut'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

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
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
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
>>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
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
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
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
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
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.

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-02-29 1:21:39 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search