Why the world hates Hungarian notation?
-
Most of the devs I know would tie it back to the data it represents and accounting systems call it Account Number, even if it might be a string. In fact my own accounting system has "Account Numbers" that include letters to differentiate types of clients. When someone calls and I ask for their Account Number, there's never any confusion.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
Can your (human) clients differentiate between 0 (zero) an O? A l and 1?
-
Well I've got to say that between
lAccNumandaccountNumber, the latter clearly indicates what the type is.Regards, Nish
My technology blog: voidnish.wordpress.com
-
I'm about to write the coding standards doc for a team. I've been using Hungarian notation ever since I stated coding. The blogs that I read online rant against use of Hu system on OO languages, but I have few questions: Though it's C++ or C#, we do have primitive data types everywhere. In fact, for smaller projects, primitive data types would account for 90% of the variables. Now I'm dealing with a lot of nummbers , flags & so on. How do I know what datatype it is? For example, the code is a 100K line code and I cannot copy the entire project to my disk to review that at home. I choose to copy a 300 lines code block with multiple functions to review it at home. I just open it in notepad and try to figure out what datatypes all these variables are. No where I can figure out this. Then why the heck everybody rants against this convention? I'm going ahead insisting on sticking with the Hu notion. If anybody has a valid reason against it, I'm all ears to it. (if you dont like Hu notation, please dont express it with the 1 vote here :sigh: )
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
I used to use Hungarian notation when working in a weakly-typed language, but quickly gave it up when working with C# and .NET. It wasn't just because C# is strongly typed; it was also because of: - Property names and data binding - Mapping database table and column names to classes and ORM's - Serializing / deserializing objects to / from XML - Configuration files - Reflection. Hungarian notation might be fine if your "names" never see the light of day; in most other cases, it gets ugly and geeky really fast.
-
Sure, we can always find difficult issues - the idea is to find ways to make our code more readable and understandable for whoever has to maintain it. My style has changed a lot over the passed 44 years of coding and it is still changing as I discover better ways of making my code more reliable and more maintainable. It's really frustrating, for example, when I am reading someone elses code that makes it impossible to tell a local variable from a class level variable - maybe that does not bother you but it does me. I certainly welcome any ideas for making my code better; however, not doing the best that I can to let the reader know about the type, scope, and usage of a variable is a non-starter for me.
David Roh wrote:
Sure, we can always find difficult issues - the idea is to find ways to make our code more readable and understandable for whoever has to maintain it.
Yes that is a common way to rationalize subjective preferences.
David Roh wrote:
It's really frustrating, for example, when I am reading someone elses code that makes it impossible to tell a local variable from a class level variable - maybe that does not bother you but it does me.
Nope that doesn't happen to me. What does happen to me is that I get frustrated when I realize the code has no error checking. Or is ignoring part of the API Is it supposed to be interacting with. Or it is just doing something wrong with the API. Or it has some horribly inefficient design based on a piece of code that by definition must handle high volumes. And other types of problems like that. If my most serious problem or even close to most serious problem was confusion about the type of a variable then I would suspect that I had moved into an alternative reality.
David Roh wrote:
I certainly welcome any ideas for making my code better; however, not doing the best that I can to let the reader know about the type, scope, and usage of a variable is a non-starter for me.
And I welcome ideas that objectively make code better. I do however realize that most ideas not not backed by anything objective. I also recognize as well that vast majority of development problems do not have anything to do with the minor subjective details of syntax. Similar to worrying about what color of nail polish works best while ignoring the symptoms of a heart attack.
-
I'm about to write the coding standards doc for a team. I've been using Hungarian notation ever since I stated coding. The blogs that I read online rant against use of Hu system on OO languages, but I have few questions: Though it's C++ or C#, we do have primitive data types everywhere. In fact, for smaller projects, primitive data types would account for 90% of the variables. Now I'm dealing with a lot of nummbers , flags & so on. How do I know what datatype it is? For example, the code is a 100K line code and I cannot copy the entire project to my disk to review that at home. I choose to copy a 300 lines code block with multiple functions to review it at home. I just open it in notepad and try to figure out what datatypes all these variables are. No where I can figure out this. Then why the heck everybody rants against this convention? I'm going ahead insisting on sticking with the Hu notion. If anybody has a valid reason against it, I'm all ears to it. (if you dont like Hu notation, please dont express it with the 1 vote here :sigh: )
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
Hungarian notation is very useful as long as you don't concatenate too many prefixes and you only use it when it actually helps.
I find the 'm_' prefix for class member and the 'p' prefix for pointer very helpful and will protest at code that doesn't use it. After using 'm_', I feel free to add another prefix as in 'm_pCursor' as this remains easy on the eye. After using the 'p' prefix I really want a capital letter so that the p stands alone and is not mistaken for anything else. For me, prefixing the data type is secondary to this as most IDEs will tell you the data type simply by hovering the mouse.
I use 'n' when my logic requires a positive whole number and 'i' when my logic requires an iterator although its implementation may be size_t or int depending on the need to use -1 to represent it pointing nowhere.
I use prefixes for controls btnName, edtName.
I use established concatenations such as lpzString but try to avoid creating new ones. -
So far, no matter what, a great potential for confusion arose between CP members, imagine in between non-hamsters.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson "Our heads are round so our thoughts can change direction." ― Francis Picabia
Hungarian notation or not, just leave out the damn underscores!!!
Randy
-
In every accounting system I've ever used, your assumption would be wrong. ;P
Will Rogers never met me.
I'd say that symbol vs meaning is philosophically always going to make that perfect symbol an impossibility. Code should be self-documenting, but any project should also document beyond the code! My rule of thumb is to use Hu for distinguishing type details (zero-termed, length-specified, pointer or value, etc.) especially in COM, say; and for module-level designation. For me, I think it's fair to make a person look into what a variable is/means, but its symbol should let them know where to look. What bugs me are magic symbols that just appear in a tight context, like a function.
JonShops -- Fun really begins with the words, "So what in the World do I do now?"
-
I've never liked it from the first time I saw it (it was in the standard at one place I worked -- using C) and I never use it in my own code. It's silly and you would have to change the variable name if you change the datatype. Having said that; here's the right way: http://www.joelonsoftware.com/articles/Wrong.html[^]
Having re-read the article, there is a distinction between App Hungarian and the loathed System Hungarian. In the original, the notation denoted the usage type rather than the data type. This means the data type may change, but the notation does not.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Having re-read the article, there is a distinction between App Hungarian and the loathed System Hungarian. In the original, the notation denoted the usage type rather than the data type. This means the data type may change, but the notation does not.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
Exactly.
-
I'm about to write the coding standards doc for a team. I've been using Hungarian notation ever since I stated coding. The blogs that I read online rant against use of Hu system on OO languages, but I have few questions: Though it's C++ or C#, we do have primitive data types everywhere. In fact, for smaller projects, primitive data types would account for 90% of the variables. Now I'm dealing with a lot of nummbers , flags & so on. How do I know what datatype it is? For example, the code is a 100K line code and I cannot copy the entire project to my disk to review that at home. I choose to copy a 300 lines code block with multiple functions to review it at home. I just open it in notepad and try to figure out what datatypes all these variables are. No where I can figure out this. Then why the heck everybody rants against this convention? I'm going ahead insisting on sticking with the Hu notion. If anybody has a valid reason against it, I'm all ears to it. (if you dont like Hu notation, please dont express it with the 1 vote here :sigh: )
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
VuNic wrote:
For example, the code is a 100K line code and I cannot copy the entire project to my disk to review that at home. I choose to copy a 300 lines code block with multiple functions to review it at home.
100k of code? correct me if i am wrong: this amount of code fits on everything which was produced since the late 80s. I think that the main intention for advising not to use hungarian notation: hungarian notation is redundant information to your declaration.
-
VuNic wrote:
For example, the code is a 100K line code and I cannot copy the entire project to my disk to review that at home. I choose to copy a 300 lines code block with multiple functions to review it at home.
100k of code? correct me if i am wrong: this amount of code fits on everything which was produced since the late 80s. I think that the main intention for advising not to use hungarian notation: hungarian notation is redundant information to your declaration.
100K lines of code is 1,00,000 lines of code right? Then I'm wrong. It should be around 1,30,000+ considering the code that we later converted as libraries. It was a medical research project. It was HUGE. Not just these, I've worked on projects that casually run over 100K lines of code. Of course I do not write them from scratch but clean the scratches here and there. And some show stopping critical fixes too. I'm still finding Hu notation to be helping, I'm sticking with it for C#. :)
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.