» Hungarian in .NET
Not Logged In.
Edit My Profile
Write for Us
Link To Us
Learn Visual Studio
Learn C# (CSharp)
Learn Web Services
Learn SQL Reporting
Learn Windows Forms
Learn Crystal Reports
ASP.NET 2.0 Examples
Shopping Cart Ecommerce
Charts and Dashboards
Opinion / Editorial
Crystal Reports Alliance
ASP.NET Developer's Cookbook
Add To Favorites
Email To Friend
Rate This Article
Hungarian in .NET
J. Ambrose Little
This article has not yet been rated.
Views (Total / Last 10 Days):
Pros & Cons
Reasons Why Not to Use Hungarian Notation
Pros & Cons
Nearly instant recognition of identifier type, assuming familiarity with abbreviations used.
Easily distinguish between two or more identifiers of different types used to reference the same conceptual entity.
If you change an identifier’s type, you must change the identifier itself and all references to it.
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.
Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names (such as “sdr” for SqlDataReader).
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?
There are too many different types to create meaningful, unique abbreviations for, particularly in an object-oriented system.
Abbreviation systems vary from company to company and even from person to person—it adds an unnecessary learning curve.
Never applied consistently, even by Microsoft.
« (Page 1)
View Entire Article
(Page 3) »
2007-04-13 5:51:10 AM
Pretty useful information for me. I wish I found this article earlyer.
Here we go again!
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.
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 ..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!
2006-10-29 10:51:44 AM
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.
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.
Can't Move Me! Part 2
2006-01-04 1:39:45 PM
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.
Can't Move Me!
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
Ugh. Hungarian makes so much more sense!
Kevin L. Kitchens
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.
J. Ambrose Little
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.
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 ?
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?
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.
Best Practices Guidelines
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.
J. Ambrose Little
2005-01-28 11:51:01 AM
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.
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.
©Copyright 1998-2019 ASPAlliance.com | Page Processed at 2019-04-24 6:23:38 PM
Link To Us