While going through a blog post written by Eric Lippert “What’s Up With Hungarian Notation?” I got really confused as he had religiously lawyered the use of Hungarian notation and kind of ridiculed those who were not in favor of using it.
It took me long time and some getting used to off to move from Hungarian notation so arguments given by him didn’t make sense to me, if I wouldn’t have known that the article was written by Eric I would have ignored it as written by someone who is ill informed and wrote it just for the sake of it. Respect for Eric made me think about what he was saying and then everything started making sense. Article was 10 years old, written on “12th Sept 2003″ and it was written under COM Programming. 10 years is a long time for IT and way we have been coding has changed drastically, Platform he was talking about wasn’t having IDE support that we have now.
Some comments he had:
“The Hungarian prefix tells you the semantic usage, not the storage type. A cBar is a count of Bars whether the storage is a ushort or a long.”
Agreed, Hungarian notation which was invented by a “Hungarian” Microsoft programmer Charles Simonyi was intended to specify the end use of the variable you were declaring. It was supposed to help programmers identify its use by looking at the name. It saved lots of time of finding that particular variable in your code and understanding what it was really meant for.
“Annotate the semantics, not the storage. If you change the semantics of a variable then you need to also change every place it is used!”
This argument was given by Eric against “If I need to change the type from, say, unsigned to signed integer, I need to go and change every place I use the variable in my code”. Eric is correct here as people do misuse Hungarian notation in there code and then blame the notation for being a wrong coding practice.
“But the benefit of knowing that you will never accidentally assign indexes to counts, or add apples to oranges, is worth it in many situations.”
Again agreed, it does solve the issues and help in preventing bugs while coding. I’ve seen many benefits of this when I used to follow Hungarian notation.
All three arguments are very valid and all three argument make sense if you read his article but
- “The Hungarian prefix tells…. ” So does intellisense if you hover over a data member in any modern IDE (including SharpDeveloper which is just 15 MB download)
- “Annotate the semantics, not the storage……” you don’t need it now “See point 1”
- “But the benefit of knowing….” Same benefit is with intellisense if you add proper Summary tags while coding. It will tell you details of what you are working “messing” with.
So, Hungarian notation is good in scenarios where you don’t have proper IDE support, where semantics are to be maintained by developers rather than IDE but if you see with time we have moved far ahead of the benefits provided by Hungarian notation. Choose your coding standards smartly as tomorrow someone else might be working on the code you are writing today and you don’t want to be “The Bad Guy” coder for that person.
PS: Now Microsoft is also preaching Pascal /Camel Casing. Go through this link for more info.