Why the world hates Hungarian notation?
-
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:
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.
I doubt that is generally true. Especially since, presumably, you are not claiming that one should use hungarian for local variables.
VuNic wrote:
How do I know what datatype it is?
Context and naming. Are you unsure about the types of the following variables? fullName = lastName + " " + firstName; connection.Commit(); for(int i=0; i < accounts.Count; i++)
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.
Say what? Your "disk"? Where exactly do you work? Exactly what kind of "computer" do you have at home? My memory stick is old and cheep when I bought it yet it holds everything I need to move entire code trees (plural at the same time.) Just one of the code trees that I commonly move around has 7,000+ files on it and probably 90% of those are source files (and I do not do GUIS, so there are no image files of any sort.) So if you presume 5000 files with 100 lines on average then that one code tree has 500,000 lines of code. I suspect the actual count is higher. And how exactly are you going to "work" on something at home if the piece you are working on, in some context, is not complete?
VuNic wrote:
f anybody has a valid reason against it, I'm all ears to it.
Because it will not provide any measurable benefit AND because as a standard it will annoy probably everyone else except you. And morale has been proven to have an impact on productivity.
-
Custom types are easy - I just use the class name only starting with a lower case letter
-
David Roh wrote:
Custom types are easy - I just use the class name only starting with a lower case letter
And what do you use for a template that references two other templates where those reference other classes?
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.
-
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.
It's a subjective preference of course, so there's not absolute reason(s). Back in the day I used Hu notation; we pretty much all did when it was the "thing you should do". However, here are some points that collectively tilt the scale towards not using Hu these days. * Hu originally solved a problem, the difficulty of quickly differentiating typed variables in primitive development environments. However the modern use of more powerful IDE's having more robust intellisense or similar capabilities that make it trivial to "see" applicable metadata about variables (etc) addresses the need for a quick means of figuring out what is what. Though you say you like to take snippets of logic to review in a simple text editor rather than "have the entire project" local and use your IDE of choice, I would think that you are an exception. Using source repositories it is trivial and normal to have a copy of all source on your workstation or laptop, to work "disconnected", and to synch delta on either side up with the repository when connected and you wish to. I'm not sure what benefit you would gain from working with snippets in a "dead" environment, when it is so easy to work on a compilable, runnable local version. For that matter, these days the source repository is generally only a VPN connection away unless you are on the road or in the air in most corporate environments. This usage of snippets to take home may be an old habit of yours that bears reevaluation; maybe it's no longer necessary. * In the style of OOP currently en vogue, injection is often favored. Many things that used to be variables are often parameters or properties now. Any localized variables tend to be very localized, as in declared very close to their usage, and at method scope or even less (lambdas, etc). Short, concise methods are greatly preferred over long rambling ones, making it much more likely that variable declaration is in close proximity to its usage. * Refactoring is commonly practiced, ideally altering implementation while maintaining functionality. What is a double today might be an int tomorrow; a string might become a char[] or vice versa. Ideally the name shouldn't need to change. Related to this, is the consideration of once and only once; if the name of a variable contains some token or segment that is a direct reinstatement of its (original) underlying type, you have effectively duplicated the information. If the underlying type changes, the "duplication" of the original type information should als
-
Well, I am a firm believer in Hungarian and here is why - I believe that the name of a variable should instantly convey three vital pieces of information to the dev: - it's type and I do mean type as in compiler typeof not semantics (regardless of what Charles did or did not intend) - it's scope - is it local, a parameter, is it a passed in reference, a class level variable - a clear indication of it's function or purpose Different devs have their own view on how to write code; however, I believe that it's better to have a good logical reason for a belief rather than just a prejudice. I believe that one of the reasons that Hungarian is considered bad is due to the way that many devs implement it - that is, each group uses very short abbreviations that are not clear to someone who is not part of the team so when you look at another teams code, you have to learn their abbreviations. Different teams have different rules and different ways of implementing Hungarian which make it a hassle to read another teams code. I believe that it is not Hungarian that is the problem but rather the way that it is implemented that is the problem. First we do very little abbreviation and only if it is an abbreviation that is so common that a noob would clearly understand it. We use longer names - yes we believe in self documenting code which means my manager should be able to read my code and understand what is being implemented in general terms (we don't however go to extremes). If a passed in parameter is a reference that will live after a function is finished, then it is important to know that altering it can have long term consequences. If a variable is a class level variable, it is extremely important to know. It should also be obvious that the more accurate the variable name clearly indicates it's purpose and function, the less potential there is for another dev to misunderstand or the original dev when returning to old code. Saying that Intellisense will solve the problem or that we can mouse over a variable is not a solution because when we read code and think we understand, we rarely mouse over or use Intellisense on what we think we already understand. Saying that Hungarian is bad because the type might change is a really weak argument - in the first place, types don't usually change that much; second, if a type does change, I certainly want to know; and lastly, with today's IDE refactoring capability, is really that hard to change a variable name (it's certainly easy for me). We c
David Roh wrote:
Different devs have their own view on how to write code; however, I believe that it's better to have a good logical reason for a belief rather than just a prejudice.
Devs come up with all sorts of ways to rationalize that their personal subjective preferences are objectively better.
David Roh wrote:
Saying that Intellisense will solve the problem or that we can mouse over a variable is not a solution because when we read code and think we understand, we rarely mouse over or use Intellisense on what we think we already understand.
In my experience, I can't recall ever seeing a single bug traced to a misunderstanding of the type. On the other hand there are vast other categories of bugs that show up over and over again and which cost businesses real money to find and fix. So given your stict approach to just variable naming could you provide some detail as to what other process practices you mandate to insure that real and costly errors which impact development efforts do not show up as well?
David Roh wrote:
...but I find it difficult to believe that any professional dev
You must really work in some different domains than I do. In the sectors that I work am I am just happy to come across code (like whole methods and classes) that are easily understood from a functional point of view. Too often I come across code with problems like the following. - Code that was obviously never tested fully - Code that was never even used. - Code that was not even appropriate for the business (no known use ever.) - Code that does absolutely no error checking. - Code that is so convoluted and has such a high coupling that it scares me just to look at it. And of course there is no unit tests for such code.
-
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
accountNumber in some cases would be a string. Just because it says "Number" doesn't mean it is an integer or a double.
-
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 would put forward a couple of reasons that Hu notation is not needed and why I do not use it. 1) All the names I assign within my objects (properties, methods, fields, etc.) derive there name based on what the business owners call it in the real world if there is a corelation. As a developer I can only do my job well when I also understand the real world objects that my code represents. As such a new developer must obtain some level of this knowledge for the data types to be evident. The example of AccountNumber in above posts should be understood within the logical context of your system. If I call a variable accountNumber then likely I have some idea of what that account number is within the context of my system. Hu notation will not tell me anything more than the common business knowledge will. The reality is that if I name it strAccountNumber all I know is that it is a string of some length. I would not be able to know simply from the "str" if the business rules allow special characters, if the max length was 8 characters, etc. 2) Modern IDE's virtually remove the need for Hu notation. If the declaration of a variable is not in view and the data type is not apparent based on my knowledge of the business domain then (as a .NET developer) all I have to do is hover over the variable and the type is immediate shown thanks to intellisense.
-
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.