Hungarian Notation in .Net - Yes or No?
-
originSH wrote:
Combined with intelligence
:laugh: You probably meant IntelliSense, but some intelligence on the top of it of course does not harm. :rolleyes:
Don't follow any man spiritually, don't do anything that will get you in sh*t if god is real - Bradml[^]
-
John Simmons / outlaw programmer wrote:
It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names
With any recent IDE, just holding the Cursor over the variable name does show the type. I cant see the point in prefixing rubbish to the name. I can cope with it, but I simply don't get the point. Maybe it is lack of practice, maybe insisting on hungarian notation comes out of lack practice reading code without it.
Failure is not an option - it's built right in.
Yes, but until source code, diff tools and the like gain the ability to compile (or at least parse) source code to the point where they too can offer such features, there may still be a need. There is something to be said for diff/merging a 100K+ source code file without having to keep scrolling upward just verify the type of a variable involved in a conflict. Having the notation there does not hurt those that do not want it there (they are adults, they can ignore it), but not having it there does hurt those that need it (whatever their reasons/needs may be). Peace!
-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles -
Damn, you beat me to it. :doh:
Cheers, Vıkram.
After all is said and done, much is said and little is done.
-
Yeah, I'm still trying to decide on this one. "ID" is the more common everyday form but they have a point that it's not actually an acronym.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Unless you assert it to stand for, my personal classic, "Identification Datum".:->
-
Damn, you beat me to it. :doh:
Cheers, Vıkram.
After all is said and done, much is said and little is done.
Damn, you both beat me, but I got the singular correct. ;P
-
I recently posted a C# article and as a C++ programmer is wont to do, I used hungarian notation on all my variables. This has generated a bit of discussion in the comments for the article, and not wanting to be completely close-minded about it, I decided to google it. Here's what I've found so far: 0) It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names. The best response to that statement was this little gem: "If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either." I could not have said it better myself. Maybe this outlook by Microsoft is why Vista is such garbage, or why the ORCAS Beta 2 is so transiently reliable. Just because some self-important evangelist from Microsoft says it doesn't make it gold. Translation - this claim is pretty weak. This is from Microsoft's coding guidelines:
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.It looks to me like they're putting the emphasis on reading code squarely on the end user instead of the developer. Hello!? We're programmers, and we can't be bothered by trying to figure out what type a variable is supposed to be. Sure, code should be easy to read, but that trait is introduced with meaningful variable and function names, not by removing ancillary information about the variables being used. 1) If you change the variable's type, it all of a sudden invalidates the name of the variable. Ever heard of Find/replace (with case matching and whole word turned on)? Besides, I can count on one hand how many times I changed the type of a variable in the last 18 years of C++ work. 2) Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names. Ummm, how can a single lowercase character move the emphasis from the following variable name to the type itself. Further, hungarian notation in no way promotes the creation of "poor variable names". I can't recall ever hearing a programmer say, "Yep, using hungarian notation so that means I can skimp on the rest of the variable name." There are other equally invalid reasons put forth by all manner of know-it-alls, but I got bored typing this stuff. ------John Simmons / outlaw programmer wrote:
Microsoft: Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type.
There is no reason that the two cannot live together. Just because you prefix (and/or use Hungarian notation with) a variable name with a mnemonic for its type does not automatically mean that the rest of the variable name is garbage.
int UserNameIndex; // int-based indexing
string UserNameIndex // string-based indexing// Or...
int iUserNameIndex;
string sUserNameIndex;While both are an index, the type of indexing in use may be different, especially if users can be referenced by both a string (i.e. last name) or an ordinal index. (Anyone that has ever written or had to deal with a string-based key in a dictionary or string indexer knows what I am talking about.) Besides, as I wrote in a previous response, those that do not like prefixing can very easily ignore a prefix that is there and pay attention to the rest of the variable name if they want to. However, a maintenance developer that is used to using the prefixes as a debugging/understanding aid will react negatively to their absence. When it comes to making source code more understandable by others, I am of the humble opinion that it is better to have something and not need it than to need something and not have it. I would rather have a developer looking at my code and saying something like: "Well, duh, I know this is a
doublevariable," rather than "what kind of variable is this?" Same thing with comments - better to have someone read them and wonder why I am commenting something that is obvious (to the reader), rather than give a less experienced developer the chance to misunderstand what I am trying to do in the code. Peace!-=- James
Please rate this message - let me know if I helped or not! * * *If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See -
I recently posted a C# article and as a C++ programmer is wont to do, I used hungarian notation on all my variables. This has generated a bit of discussion in the comments for the article, and not wanting to be completely close-minded about it, I decided to google it. Here's what I've found so far: 0) It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names. The best response to that statement was this little gem: "If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either." I could not have said it better myself. Maybe this outlook by Microsoft is why Vista is such garbage, or why the ORCAS Beta 2 is so transiently reliable. Just because some self-important evangelist from Microsoft says it doesn't make it gold. Translation - this claim is pretty weak. This is from Microsoft's coding guidelines:
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.It looks to me like they're putting the emphasis on reading code squarely on the end user instead of the developer. Hello!? We're programmers, and we can't be bothered by trying to figure out what type a variable is supposed to be. Sure, code should be easy to read, but that trait is introduced with meaningful variable and function names, not by removing ancillary information about the variables being used. 1) If you change the variable's type, it all of a sudden invalidates the name of the variable. Ever heard of Find/replace (with case matching and whole word turned on)? Besides, I can count on one hand how many times I changed the type of a variable in the last 18 years of C++ work. 2) Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names. Ummm, how can a single lowercase character move the emphasis from the following variable name to the type itself. Further, hungarian notation in no way promotes the creation of "poor variable names". I can't recall ever hearing a programmer say, "Yep, using hungarian notation so that means I can skimp on the rest of the variable name." There are other equally invalid reasons put forth by all manner of know-it-alls, but I got bored typing this stuff. ------All the arguments you disagree with make pretty good sense. But it's getting to an almost religious level of discussion here. Rather come up with some typical examples to give the discussion substance. Usually you'd use variables like: - string customerName, why use sCustomerName here? It hurts the eyes, and intellisense shows you the type if you insist on knowing, and the compiler does the type checking. - Bit more tricky: some kind of distance variable: double buildingLength. This could be ok, if the system has standardized length variables (e.g. metric systems). But if the unit is different than expected, it's better to chose buildingLengthInInches e.g. - What to do with more complex variables? E.g. of type Dictionary<int, List<Customer>>. Usually I go for a pretty verbose naming scheme: IdToCustomerList. Unless the names get really really long, I stay away from using abbrevations, because with autocompletion readability outweights abbrevations usually. So in 90% of the cases hinting on the type doesn't make much sense. But there's some cases where it does, there's no need to be completely black and white.
Wout
-
Chris Maunder wrote:
they have a point that it's not actually an acronym
1. I try to go with natural language. 2. Somebody here said ID stood for Identifying Datum. :~
Cheers, Vıkram.
After all is said and done, much is said and little is done.
Vikram A Punathambekar wrote:
2. Somebody here said ID stood for Identifying Datum.
That was me, back in March. I'm glad it was well remembered, because I have no basis for saying that except defending my use of the uppercase D. It was the aspirant lawyer in me breaking out.
-
I recently posted a C# article and as a C++ programmer is wont to do, I used hungarian notation on all my variables. This has generated a bit of discussion in the comments for the article, and not wanting to be completely close-minded about it, I decided to google it. Here's what I've found so far: 0) It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names. The best response to that statement was this little gem: "If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either." I could not have said it better myself. Maybe this outlook by Microsoft is why Vista is such garbage, or why the ORCAS Beta 2 is so transiently reliable. Just because some self-important evangelist from Microsoft says it doesn't make it gold. Translation - this claim is pretty weak. This is from Microsoft's coding guidelines:
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.It looks to me like they're putting the emphasis on reading code squarely on the end user instead of the developer. Hello!? We're programmers, and we can't be bothered by trying to figure out what type a variable is supposed to be. Sure, code should be easy to read, but that trait is introduced with meaningful variable and function names, not by removing ancillary information about the variables being used. 1) If you change the variable's type, it all of a sudden invalidates the name of the variable. Ever heard of Find/replace (with case matching and whole word turned on)? Besides, I can count on one hand how many times I changed the type of a variable in the last 18 years of C++ work. 2) Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names. Ummm, how can a single lowercase character move the emphasis from the following variable name to the type itself. Further, hungarian notation in no way promotes the creation of "poor variable names". I can't recall ever hearing a programmer say, "Yep, using hungarian notation so that means I can skimp on the rest of the variable name." There are other equally invalid reasons put forth by all manner of know-it-alls, but I got bored typing this stuff. ------Well first off, I’d like to thank you. This is why, I move between C, C++ and C# a lot these days which is well bloody annoying. I’ve just read your post and it hit me... do I still use it, as it’s a very subconscious thing when I’m creating variables. So I opened three instances of VS and loaded up 1 project from each language and took a look (my latest projects in each) and its funny but they are all the same in the use of the notation... very little when compared to a c++ project from a year ago which had the correct notation. now I’m going to blame VS for this, as to see the type I just hover the cursor over the variable and up pops the variable type and name again (like I didn’t know the name of what I just hovered over). Which is well stupid because I can’t just skim read the code and understand what is really going on. So, I am now going to go and put in Hungarian notation to every single variable in all my projects (using Find and Replace) oh and backing them up first. I see the great aid of notation in that you can quickly identify the type of a variable even in notepad :) p.s i think its good coding practise myself which is why I’m a bit shocked at how little of it i do of late. Thanks again and keep at it :) pp.s Its good if everyone uses the same notation. MSDN 1998 HN List & MSDN List #2 I have seen code with the wrong tags used, eg cvarname for char Is there a solid list out there without all the C*** just a simple table list of all the notation and where there meant to be used
-
John Simmons / outlaw programmer wrote:
It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names
With any recent IDE, just holding the Cursor over the variable name does show the type. I cant see the point in prefixing rubbish to the name. I can cope with it, but I simply don't get the point. Maybe it is lack of practice, maybe insisting on hungarian notation comes out of lack practice reading code without it.
Failure is not an option - it's built right in.
jhwurmbach wrote:
With any recent IDE, just holding the Cursor over the variable name does show the type. I cant see the point in prefixing rubbish to the name.
Try doing that when someone's pasted some code into a question in one of the programming forums. That's when hungarian is really useful.
-
jhwurmbach wrote:
With any recent IDE, just holding the Cursor over the variable name does show the type. I cant see the point in prefixing rubbish to the name.
Try doing that when someone's pasted some code into a question in one of the programming forums. That's when hungarian is really useful.
In that case, the code snippet would be so short that the declaration would be immediatly above it. All in all - both your and James R. Twines argument seems a little far fetched to me.
Failure is not an option - it's built right in.
-
I've been at my Job(1st since graduating college), for about a year now, and I dont know what I'd do without the notation. I'm mostly dealing with code that has somewhere along the lines of 10000 line functions. Having to scroll up to check types for variable types only used once would be beyond a pain in the a**. So hurray for Hungarian Notation for saving me precious time and facilitating my laziness to scroll up.
[Insert Witty Sig Here]
VonHagNDaz wrote:
Having to scroll up to check types for variable types
I don't have to do that, I just hover my mouse cursor over the variable and get told its type.
-
I was never into Hungarian Notation to begin with, but... Look at C# 3.0's "var" keyword. Examples here[^] about 1/2 down. I think the var keyword might be reason to bring back Hungarian Notation, because you have no idea what type the var is unless you look at the initializer. Now, from what I've heard from others, the var keyword is really just a convenience for not typing in the complete type (which I disapprove of), but I suspect there are better uses. Marc
The biggest reason I've seen for it has to do with generic methods, the best example being from the C++ STL. Every container class defines a list of typedefs for returned classes so you can create variable of those class types with just the container as a parameter. If the developer of the original class leaves off the typedef then you can't use the return type in a generic method.
class A
{
typedef number int;
int f() { return 1; }
}class B
{
typedef number double;
double f() { return 1; }
}void f(X x)
{
X::number = x.f();
}Instead of X::number var would be much more useful.
This blanket smells like ham
-
I recently posted a C# article and as a C++ programmer is wont to do, I used hungarian notation on all my variables. This has generated a bit of discussion in the comments for the article, and not wanting to be completely close-minded about it, I decided to google it. Here's what I've found so far: 0) It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names. The best response to that statement was this little gem: "If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either." I could not have said it better myself. Maybe this outlook by Microsoft is why Vista is such garbage, or why the ORCAS Beta 2 is so transiently reliable. Just because some self-important evangelist from Microsoft says it doesn't make it gold. Translation - this claim is pretty weak. This is from Microsoft's coding guidelines:
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.It looks to me like they're putting the emphasis on reading code squarely on the end user instead of the developer. Hello!? We're programmers, and we can't be bothered by trying to figure out what type a variable is supposed to be. Sure, code should be easy to read, but that trait is introduced with meaningful variable and function names, not by removing ancillary information about the variables being used. 1) If you change the variable's type, it all of a sudden invalidates the name of the variable. Ever heard of Find/replace (with case matching and whole word turned on)? Besides, I can count on one hand how many times I changed the type of a variable in the last 18 years of C++ work. 2) Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names. Ummm, how can a single lowercase character move the emphasis from the following variable name to the type itself. Further, hungarian notation in no way promotes the creation of "poor variable names". I can't recall ever hearing a programmer say, "Yep, using hungarian notation so that means I can skimp on the rest of the variable name." There are other equally invalid reasons put forth by all manner of know-it-alls, but I got bored typing this stuff. ------I don't mind Hungarian notation (the false kind that's practiced now, or the original kind[^]), which, ironically for you, was invented by a Microsoft programmer. Personally, once I started coding in C#, I abandoned all Hungarian notation and found it quite liberating. It now seems superfluous to put a character at the beginning of each variable just to define the type. Simply put, I've never once thought to myself, "gee, is it a boolean? Or a string?"
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Orthodox Jews are persecuting Messianic Jews in Israel (video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
In that case, the code snippet would be so short that the declaration would be immediatly above it. All in all - both your and James R. Twines argument seems a little far fetched to me.
Failure is not an option - it's built right in.
What? Are you new here? When did you last see someone asking questions in one of the programming forums who bothered to include declarations in their code snippets? My point is that yes, Hungarian notation is pretty unnecessary in an IDE. That's not the only place you ever see code, however.
-
I've been at my Job(1st since graduating college), for about a year now, and I dont know what I'd do without the notation. I'm mostly dealing with code that has somewhere along the lines of 10000 line functions. Having to scroll up to check types for variable types only used once would be beyond a pain in the a**. So hurray for Hungarian Notation for saving me precious time and facilitating my laziness to scroll up.
[Insert Witty Sig Here]
VonHagNDaz wrote:
has somewhere along the lines of 10000 line functions
Don't plan around abuses. Hungarian notation is superfluous in any sane-sized method.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Orthodox Jews are persecuting Messianic Jews in Israel (video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
I think you just hit the issue on it's head. If hungarian has value: use it If not: don't. 10,000 line methods (just breath easy and relax, just breath easy and relax, jus ..) gives hungarian notation value whereas for 20 line methods it provides none since the variable declarations are still visible. Add to that the lack of pointer indirection in .net (one of the more egregious uses of notation in c++ it seems), an advanced IDE and the overwhelming diaspora of objects, hungarian notation seems to have little application. Still, I have worked in places where it was not just used but patently abused. I should really post a wtf on that memory :)
I'm largely language agnostic
After a while they all bug me :doh:
MidwestLimey wrote:
If hungarian has value: use it
I remember a blog or article on Hungarian notation in which the author decried the common use of it to denote primitive types, in contrast to its inventors' original intention of it indicating type and purpose, so proper use is (excuse my C/C++) lpcStr or something like like. I still use the concept in UI, but to break with my grimy VB6 past, I now prefix TextBox control names with 'text', e.g. textSurname, to go on, optionYes and optionNo etc.
-
What? Are you new here? When did you last see someone asking questions in one of the programming forums who bothered to include declarations in their code snippets? My point is that yes, Hungarian notation is pretty unnecessary in an IDE. That's not the only place you ever see code, however.
Craster wrote:
What? Are you new here?
Sortof - only 1.2KPosts. Oh my God!:omg: *runs of to the "Anonymous CodeProjecters" meeting* The kind of people who poste incorrect codesnippets to the forum are those that would not even know there is something like hungarian notation. Much less using it correctly. So in that case, I think the whole procedure is of little value.
Failure is not an option - it's built right in.
-
I was never into Hungarian Notation to begin with, but... Look at C# 3.0's "var" keyword. Examples here[^] about 1/2 down. I think the var keyword might be reason to bring back Hungarian Notation, because you have no idea what type the var is unless you look at the initializer. Now, from what I've heard from others, the var keyword is really just a convenience for not typing in the complete type (which I disapprove of), but I suspect there are better uses. Marc
Marc Clifton wrote:
I think the var keyword might be reason to bring back Hungarian Notation, because you have no idea what type the var is unless you look at the initializer.
Why use var if you know the type so quickly?
-
I recently posted a C# article and as a C++ programmer is wont to do, I used hungarian notation on all my variables. This has generated a bit of discussion in the comments for the article, and not wanting to be completely close-minded about it, I decided to google it. Here's what I've found so far: 0) It seems that Microsoft thinks we should abandon it in favor of "more natural english-like" variable names. The best response to that statement was this little gem: "If Microsoft said I shouldn't comment my code, it wouldn't stop me from doing that, either." I could not have said it better myself. Maybe this outlook by Microsoft is why Vista is such garbage, or why the ORCAS Beta 2 is so transiently reliable. Just because some self-important evangelist from Microsoft says it doesn't make it gold. Translation - this claim is pretty weak. This is from Microsoft's coding guidelines:
Use names that describe a parameter's meaning rather than names that describe a parameter's type. Development tools should provide meaningful information about a parameter's type. Therefore, a parameter's name can be put to better use by describing meaning. Use type-based parameter names sparingly and only where it is appropriate.It looks to me like they're putting the emphasis on reading code squarely on the end user instead of the developer. Hello!? We're programmers, and we can't be bothered by trying to figure out what type a variable is supposed to be. Sure, code should be easy to read, but that trait is introduced with meaningful variable and function names, not by removing ancillary information about the variables being used. 1) If you change the variable's type, it all of a sudden invalidates the name of the variable. Ever heard of Find/replace (with case matching and whole word turned on)? Besides, I can count on one hand how many times I changed the type of a variable in the last 18 years of C++ work. 2) Puts an emphasis on the type instead of the descriptive identifier name—encourages poor variable names. Ummm, how can a single lowercase character move the emphasis from the following variable name to the type itself. Further, hungarian notation in no way promotes the creation of "poor variable names". I can't recall ever hearing a programmer say, "Yep, using hungarian notation so that means I can skimp on the rest of the variable name." There are other equally invalid reasons put forth by all manner of know-it-alls, but I got bored typing this stuff. ------Here's a blog post from one of the early C# team members. http://blogs.msdn.com/ericgu/archive/2007/02/01/properties-vs-public-fields-redux.aspx[^] If you are writing a library that will get used by a number of different languages, all the hungarian notation is ugly and confusing. If your code isn't going to be public for some level of public, just do what makes everyone happy.
This blanket smells like ham
