Hungarian Notation in .Net - Yes or No?
-
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 too went to .NET from a Win32/MFC background, and found it strange - userName instead of strUserName felt awkward at first, but now it's the other way round. Besides, if you were to continue using Hungarian, your variable names would clash savagely with the framework's names (and others' ;) ). I'll tell you what I do not like about the .NET naming conventions, though - I think camelCase is way better for method names. [ducks]
John Simmons / outlaw programmer wrote:
the ORCAS Beta 2 is so transiently reliable
I'd never install MS (or for that matter, most) betas. Unless the client wanted something to be oh-so-ready for the future.
Cheers, Vıkram.
After all is said and done, much is said and little is done.
-
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]
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:
-
:) I too went to .NET from a Win32/MFC background, and found it strange - userName instead of strUserName felt awkward at first, but now it's the other way round. Besides, if you were to continue using Hungarian, your variable names would clash savagely with the framework's names (and others' ;) ). I'll tell you what I do not like about the .NET naming conventions, though - I think camelCase is way better for method names. [ducks]
John Simmons / outlaw programmer wrote:
the ORCAS Beta 2 is so transiently reliable
I'd never install MS (or for that matter, most) betas. Unless the client wanted something to be oh-so-ready for the future.
Cheers, Vıkram.
After all is said and done, much is said and little is done.
yay for camelCase!
I'm largely language agnostic
After a while they all bug me :doh:
-
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:
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.
-
It takes a bit of getting used to but I far prefer non-hungarian notation now. I thought there would be problems with getting mixed up with types but by using sensible names (eg startDate, memberId, typeName) it's obvious as to the vague type you would expect to find in the variable
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
memberId
I use ID instead of Id. FxCop bugs the hell out of me on that one.
Cheers, Vıkram.
After all is said and done, much is said and little is done.
-
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. ------IMHO, it is sad that people waste so much energy on trivialities. Hungarian or not - who cares, as long as you use it consistently. The use of brain-damaged .NET 1.x collections is a much graver sin than any style issue one could imagine.
-
Chris Maunder wrote:
memberId
I use ID instead of Id. FxCop bugs the hell out of me on that one.
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
-
Chris Maunder wrote:
memberId
I use ID instead of Id. FxCop bugs the hell out of me on that one.
Cheers, Vıkram.
After all is said and done, much is said and little is done.
-
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 can guarantee that most of the code which claims that it uses Hungarian notation does not, in fact, do it correctly. I think most of the code just uses some type based prefix (may or may not in line with actual Hungarian notation). So the real debate is whether to use type based prefix or not (and not whether to use Hungarian notation or not). That being said I think a programmer should follow the notation/convention most appropriate for the platform/framework he is developing on. If I am developing in Java, I follow the java conventions (lower case everywhere except for class names). For C#: Framework Design Guidelines[^]. For JavaScript: something similar to Java. For VB/VBSCRIPT: Visual Basic naming conventions (Capital variable names). Also if your company has its own naming convention follow that. Fighting over which naming convention is better is useless. Another thing to note about .Net/Java is that properly written method/function code generally are really small. [My personal rule (based on Martin Fowler's book) is anything above 20 lines of code should be refactored and I have been pretty successful most of the times.] Which eliminates need for type based prefix notation. -- modified at 10:11 Monday 30th July, 2007
-
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:
more natural english-like
Looks like the Negus has infiltrated Microsoft.
Gary Kirkham Forever Forgiven and Alive in the Spirit He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot Me blog, You read
-
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
Easily solved with "thou shalt not use 'var'".... oopps, fallen into "Coding Standards" writing mode where usually the worst coder ends up writing the standards because they're no good at actually writing code. As a result, the rules are based on rubbish guidelines that have been cut and pasted since 1970. ;-) When I used the "var" keyword in my trial with .net 3.5 six months back (in the Orcas Preview), I found that I didn't need Hungarian Notation as the variable of type var was usually initialised only a couple of lines before it was used and generally I never kept it in scope for long. It was easier to stick with the style (non-Hungarian) used in the rest of the code. As an aside, I still find it annoying to writing variables including the type, such as "findButton" (especially as the IDE almost wants me to write "buttonFind" despite the C# naming advice from Microsoft) but yet I can't seem to come up with a cleaner standard.
Regards, Ray
-
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 use hungarian notation as a memory aid. Combined with intelligence it really speeds things up for me. i.e. what did I call that damn bool? keystrokes "this.b_" ahhhh there it is. I also use it to differentiate between local, private and public members. Local ones i use purely camelCasing, private have hungarian and public have properized (or whatever the programming term is). i.e. localVariable this.s_PrivateMember this.PublicMember It means I can quick tell where something has come from and with the private members allows me to quickly find a certain type. I combine that with always including "this." or "base." so that I also know if something is in this class or coming from an inherited class. I know alot of this isn't to many peoples tastes but it works for me, it allows me to quickly reabsorb the meaning of code I haven't visited in a while.
-
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:
So hurray for Hungarian Notation for saving me precious time
Until the day when someone forgets to rename a variable after changing its type. ;P How often do you really need to know a variable's type? For me it's not often. When I need it, I just hover over the variable with the cursor (inside the IDE).
Whenever an appliance, gadget, or other kind of technology you own breaks or stops performing, pray to Science for it to be saved (fixed). If it doesn't change, don't worry... just keep praying. Science works in mysterious ways! - Someone on the Internet
-
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
var is a keyword for the compiler to identify the type for you: var x; // Compile error var x = 10; // x is an int var x = null; // Compile error var x = "Test"; // x is an string var x = new { Name = "Test" }; // x is an anonymous type var x = from n in { "Test", "Test2" } select n; // x is an IEnumerable<string> I'll find it very useful for generics: var dict = new Dictionary<int, string>(); Dictionary<int, string> dict = new Dictionary<int, string>(); Don't think the second line tells you any more then the first. Oh, and don't forget, it can only be used as a variable, not for fields.
-
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.
Unnecessary that is. Use the IDE, Luke. :)
Whenever an appliance, gadget, or other kind of technology you own breaks or stops performing, pray to Science for it to be saved (fixed). If it doesn't change, don't worry... just keep praying. Science works in mysterious ways! - Someone on the Internet
-
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
-
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
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.
-
Damn, you beat me to it. :doh:
Cheers, Vıkram.
After all is said and done, much is said and little is done.
-
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
There are much better uses for var than the just for lazy programmers. One good example of where it will help is with the new LINQ support. LINQ allows the generation of new data types as the result of a query. See http://blogs.msdn.com/danielfe/archive/2005/09/22/472884.aspx[^] for an example.
-
I can guarantee that most of the code which claims that it uses Hungarian notation does not, in fact, do it correctly. I think most of the code just uses some type based prefix (may or may not in line with actual Hungarian notation). So the real debate is whether to use type based prefix or not (and not whether to use Hungarian notation or not). That being said I think a programmer should follow the notation/convention most appropriate for the platform/framework he is developing on. If I am developing in Java, I follow the java conventions (lower case everywhere except for class names). For C#: Framework Design Guidelines[^]. For JavaScript: something similar to Java. For VB/VBSCRIPT: Visual Basic naming conventions (Capital variable names). Also if your company has its own naming convention follow that. Fighting over which naming convention is better is useless. Another thing to note about .Net/Java is that properly written method/function code generally are really small. [My personal rule (based on Martin Fowler's book) is anything above 20 lines of code should be refactored and I have been pretty successful most of the times.] Which eliminates need for type based prefix notation. -- modified at 10:11 Monday 30th July, 2007
Rama Krishna Vavilala wrote:
That being said I think a programmer should follow the notation/convention most appropriate for the platform/framework he is developing on.
Amen. But let's not talk about OTBS in Java
Cheers, Vıkram.
After all is said and done, much is said and little is done.
