Why the world hates Hungarian notation?
-
I understand #2 but it's a wee bit silly. How often do you change a variable type - and even if you did the IDE asks to change all of 'em for you. It takes 3 seconds.
It occurs more often than you might be aware.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
DavidCrow wrote:
What type is it: numeric (long, int, double) or alphanumeric?
If I see
accountNumber, I'd automatically assume anInt32(.NET).Regards, Nish
My technology blog: voidnish.wordpress.com
Ah, yes, the assumption factor. When often engaged upon, oft required is the element of REfactoring! These might be more specific: thisVarIsASignedIntegerBuddyBoy dontUseThisVarToStoreNumbersBuddyBoy noSpacesOrUnderlinesAllowedBuddyBoy :wtf:oh_AndHereIsAnExceptionColumnForYouBuddetteGals_JustInCase :wtf: ;P
The best way to improve Windows is run it on a Mac. The best way to bring a Mac to its knees is to run Windows on it. ~ my brother Jeff
-
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 prefere Hunarian notation for the same reasons. We don't always have an IDE handy when reviewing code. I use "m_" for module-level scoped variables, and no prefix for variables local to a given method or property. So, what prefixes would you use for the following (and their array counterparts where arrays make sense): Int16 Int32 Int64 UInt16 UInt32 UInt64 String DateTime Single Double Boolean Dictionary/Dictionary<> List/List<> or a variety of other objects? Your choices could be helpful to us Neanderthals still using Hungarian notation?
-
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
Well argued. I simply disagree. Variable types change a lot more than you seem to be aware. Especially in an agile environment. If a variable is given a descriptive enough name, then it's underlying type is already apparent in the name. Hey, but if it works for you go for it. I'll never read your code and won't work somewhere where it's required.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun -
Hi, Thanks for the enlightenment! I was almost sure that this was the case, although most of the examples I've seen say "m_CustomerId" instead of "mCustomerId". My confusion on this probably comes from interpreting the word "member" as meaning "property, method or field", which is probably incorrect. I write _customerId myself when I need a shadow field for a property called CustomerId. That also works well. Incidentally, that's how I wrote struct field names meant to be private - which wasn't possible to enforce back then - in C back in the early 80's. I think most people did - it became a habit to see it as a bug to touch something starting with _ unless you owned (had defined) it. So using that convention now feels quite familiar and natural. When I work with other people's code I generally don't have any problem with different styles, as long as ALL public identifiers (including parameters - camelCased) strictly follow the .NET guidelines. When you've chosen your environment, stick to its conventions - otherwise you're just confusing the people who use your stuff. Most people seem to follow them, though. I occassionally see camelCasing of classes, methods and properties, but that usually only happens when a web designer/javascript coder makes an occassional visit to .NET (and that code comes to me for refactoring anyway, as a matter of procedure)... Later,
"m" most often means "module" for variables scoped to class. For example, if you have a CustomerID property, then having a m_CustomerID variable declared at the class level is the anchor for the value that the property (and other code in the class) can access. Fields are rarely ever appropriate in professional code.
-
"m" most often means "module" for variables scoped to class. For example, if you have a CustomerID property, then having a m_CustomerID variable declared at the class level is the anchor for the value that the property (and other code in the class) can access. Fields are rarely ever appropriate in professional code.
-
I don't care for Hungarian notation because it doesn't add any useful information. Consider the following two variable names: CustomerName strCustomerName There is no added value to the 'str' prefix in that example because both variables are obviously string variables. All my variable names have a tendency to make their type obvious - there is no reason to use short, confusing names where a particular notation is required. The tool tip will tell one the type anyways.
CustomerName could also be a class. such as (in shorthand): class CustomerName String FirstName String MiddleName String LastName Int32 SalutationID Int32 TitleID
-
Yes, public fields. Good catch.
-
CustomerName could also be a class. such as (in shorthand): class CustomerName String FirstName String MiddleName String LastName Int32 SalutationID Int32 TitleID
While I doubt anyone would create a CustomerName class, I think your point still stands. Regardless, I've never found Hungarian Notation to have enough benefit to stick with it - and that is after having used it for years. If someone else wants to use it that's fine with me.
-
While I doubt anyone would create a CustomerName class, I think your point still stands. Regardless, I've never found Hungarian Notation to have enough benefit to stick with it - and that is after having used it for years. If someone else wants to use it that's fine with me.
Same here. I neither recommend it nor discourage it. I do like the idea of a shared notation when working as a team.
-
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 don't even understand the question. If your C++ program is not broken up into .cpp files of less than 1000 lines, coupled usually 1-1 with .h files of less than 100 lines, there is far more wrong with your coding than hungarian notation. You know what the data type of a variable is because each class only has a few member variables, and their types are given in the .h file. If you have a boatload of global variables, or big sprawling files with a zillion classes in them, or you're declaring members public and peeking inside other classes to look at their variables, I could see how you'd have a problem remembering the types. But this is just bad practice. Hungarian notation solved a problem of the 1990's C-based world, where you had thousands of globals in a big project. That problem belongs to the past. If you have that problem now, then your code belongs to the past.
-
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.
Because it's not the 90's anymore and there are better ways to know what a variable type is? You should be using an editor that will tell you what the type is; then you will *know*. You will know even when the type changed from signed to unsigned or from short to long. Besides it has been my experience that most people use Hungarian notation so they don't have to come up with decent variable names: I always see functions with crap like this: int iValue; char *strzValue; double dValue; float fValue;
-
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 always publish a data dictionary with every project and a style guide for any deviations from "standards" and to define which "standard" I am using. A single file holds the definion and type for each variable. Easy to find the datatype and you actually know what the variable means in the real world. This also helps keep business variable names distinct and consistant across an entire project (e.g., never "name", always clientName, providerName, and clientName everywhere) which I feel is a critical practice. I also publish "global" names that are reused. (e.g., ndx is always used for the innermost indexer in loops). You can write scripts that will find most variables and add them to a dictionary. For Property-backs I use _whatever so I know I will have a Property Whatever on the object. Though I sometimes shortcut when it is very clear. (e.g., On the "Client" object I may have _clientName on the back, but "Name" on the Property. I always (and only) use type prefixes for GUI object types in stuff like ASP.net (e.g., "asp:Button btn_SaveClient") and always publish the prefixes btn =button, tb =textbox in the data dictionary. This really helps in the code behind when VS creates event handler names for you - tb_Client_OnFocus, tb_Client_TextChanged. Every naming convention is only designed to make code clearer. A data dictionary does this best (IMHO), and if you inherit multi-convention code this really helps "fix" it. (e.g., if in one file I have clntCode and in another ClientID and another intClient I can add them all to the dictionary, make sure I understand them, and then find-replace for each - clntCode int; -> clientCode Int32; ClientID decimal(6,0); -> clientCode Int32; Not perfect, but a good start. Which convention doesn't matter if you are consistant and document well. A Data Dictionary does this, provides a big step in documentation, and helps provide a global view of your application.
-
Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.
gritter55 wrote:
Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.
Are you going to concatenate, substring, replace, index any accountNumber?? For that matter, are you going to apply any methods of any type?? That make for a bad argument for why not to use a type. Anything called a Number being expressed as a numeric type would allow for the best space efficiency. Number quantities expressed as strings would result in faster display routines--still slower transfer between function calls or network protocols. Simple answer: Use the type that allows for readability.
-
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 was on a team a few years back tasked with writing coding standards. We started to define prefixes for all commonly-used types and user controls. We quickly realized that there were just too many variations for us to account for in modern Object-oriented systems. This includes dozens (or hundreds) of classes as well as custom subclassed UI controls. Additionally, Visual Studio (and other IDEs) are kind enough to display tool-tips indicating the data type. I also frequently use the "Go to definition" feature to further explore the origin of variables or types. It's important to remember that the type of some variables can change over time (i.e. Int32 to Int64 or Double to Decimal). Coupling the variable name to its type just increases the potential need for future refactoring that could be avoided by simply using a more generic (but still descriptive) name. I realize the big exceptions to the IDE-sugar are when you print code or view it in a plain text editor. But what my team decided is that these were very rare in our situation. We ended up recommending a "good descriptive name" for variables and UI controls. We realized that with the Intellisense-driven Visual Studio experience you only have to type a variable or control's name ONCE (in most cases) and Intellisense will assist with all subsequent references to it.
-
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 actually worked at a place that was very strict about Hu notations. After getting used to it, the whole thing felt super natural and I really enjoyed it. The conventions were "sane" hungarian notations, as you can go overboard with it. We had maybe 10 or so prefixes everybody knew and used. Maintaining the code was very fun. I wish more places would adopt those notations. We were coding in C, so I don't know if it would work the same for C++.
-
Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.
-
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.