Hungarian Notation in .Net - Yes or No?
-
I agree with you comments about the sort of data, just not the type. I ditched Hungarian notation a while back, but I still like 'p' for pointer, and sometimes a few others. like "is" for a boolean to make the name look like a question etc...
Paul Watt wrote:
ike "is" for a boolean to make the name look like a question etc...
I've been doing that now as well. isFooEnabled, isDisplayingBars, etc.
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 agree with you comments about the sort of data, just not the type. I ditched Hungarian notation a while back, but I still like 'p' for pointer, and sometimes a few others. like "is" for a boolean to make the name look like a question etc...
Paul Watt wrote:
"is" for a boolean to make the name look like a question
Yeah, i'm fine with that, 'cause it can actually make the code more readable:
if (isAnOddChoice),if (hasNoWhereToRun),while (noMatchFound), etc. But to me, that's just putting a bit of thought into your naming rather than picking some generic name (e.g.,Success) and tacking on a prefix. Of course, i'm totally lazy enough to do the latter at every turn, so perhaps my attitude is just a desire to force myself into using better names... ;)----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
-
That's 24 lines. Wow. I can imagine your code would be so highly componentized as to have to trace 50 layers down the call stack in order to find out what you're actually doing. I hope you're exaggerating -- to me, anywhere up to 150 lines sounds a bit more realistic.
Cyrilix wrote:
I hope you're exaggerating -- to me, anywhere up to 150 lines sounds a bit more realistic
I said "you should look at refactoring it" not that you MUST refactor it. At a quick glance I can see that the vast majority of my methods fit in one screen. That would be about 30 to 40 lines.
Cyrilix wrote:
I can imagine your code would be so highly componentized as to have to trace 50 layers down the call stack in order to find out what you're actually doing.
Not as far as that, but then my code reuse is way up on what it was when I wrote methods at 100+ lines. Also, I give things meaningful names so it is easy to see what something does without having to go into every method.
Upcoming events: * Glasgow: Mock Objects, SQL Server CLR Integration, Reporting Services, db4o, Dependency Injection with Spring ... "I wouldn't say boo to a goose. I'm not a coward, I just realise that it would be largely pointless." My website
-
Vikram A Punathambekar wrote:
I use ID instead of Id. FxCop bugs the hell out of me on that one.
Really? Because I thought the standard with acronyms and abbreviations was to uppercase for the first letter, lower for the rest. Marc
I despise using lower/Camel/Pascal case for an acronym. IMO, acronyms should always be upper case.
Software Zen:
delete this; -
Vikram A Punathambekar wrote:
I use ID instead of Id. FxCop bugs the hell out of me on that one.
Really? Because I thought the standard with acronyms and abbreviations was to uppercase for the first letter, lower for the rest. Marc
Matlab purists get tied up when you spell it 'Matlab' instead of 'MATLAB'. Apparently, 15 years ago each of those letters meant something and you better well recognize the acronym, dammit!
-
Paul Watt wrote:
ike "is" for a boolean to make the name look like a question etc...
I've been doing that now as well. isFooEnabled, isDisplayingBars, etc.
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
Judah Himango wrote:
I've been doing that now as well. isFooEnabled, isDisplayingBars, etc.
Opens up a whole new kettle of questions (I'm mixing what?). I often, late at night, get strung out over, 'isForExport', or 'mustExport', or 'useAltExport', or 'isToUseAltExport'.
-
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. ------As an old MFC hand, when I first moved to C# - I kept up the Hungarian notation for a while, but then I started to fall into the new MS standard as it made my code fit better and more readable to the VB programmers I started working with. Of course, with the latest IDE's. Knowing the type of a variable is just a mouse hover away.
Michael Thanks to all for your kind words and support on my return to CP. This place and you guys and gals are just the best
-
Judah Himango wrote:
I've been doing that now as well. isFooEnabled, isDisplayingBars, etc.
Opens up a whole new kettle of questions (I'm mixing what?). I often, late at night, get strung out over, 'isForExport', or 'mustExport', or 'useAltExport', or 'isToUseAltExport'.
Here's the trick: read the code out loud: if it comes out sounding like a bad foreign accent (or, Yoda), then you need to work on the names... ;)
----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
-
:) 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.
Vikram A Punathambekar wrote:
I think camelCase is way better for method names. [ducks]
Actually, after having spent so much time in Java over the past few quarters at school, camelCase method names feel more natural for me. I still have to think about it when I'm writing C# again.
-
Nemanja Trifunovic wrote:
brain-damaged .NET 1.x collections
What do you mean by that? The non-generic ones?
Yes. Using non-generic collections is a horrific practice in any application that has access to the generic ones.
-
Chris Maunder wrote:
hungarian notation
Now that's a notation I have not used in a long, long, long time :)
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
Paul Conrad wrote:
Now that's a notation I have not used in a long, long, long time
I Float between the two, but i've lately i've been trying to double my use of hungarian notation ;)
-
Here's the trick: read the code out loud: if it comes out sounding like a bad foreign accent (or, Yoda), then you need to work on the names... ;)
----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
:laugh: Seriously though, that's a great argument for fluent interfaces[^].
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 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.
Vikram A Punathambekar wrote:
I'll tell you what I do not like about the .NET naming conventions
The one thing I do not like about .NET naming conventions is VB and any other case insensitive langauges forcing those bloddy "_" underscores on us again. I think that key needs to be removed from everyone's keyboard! :)
Rocky <>< Latest Code Blog Post: www.TheWPFDirectory.com site launched! Latest Tech Blog Post: You got to see this - Seadragon and Photosynth!
-
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
Yeah, I agree. Funny though, when it comes to bool's I never thought I could survive without bMailWaiting or bPosts, but after .NET it seems much clearer with isMailWaiting or hasPosts... :) Oh yeah, I almost forgot, now about every method that returns a status bool for failure, now my local variable inside the method is usually "isOkay" ;) Okay, it could be "bIsOkay", but that just doesn't sound right :)
Rocky <>< Latest Code Blog Post: www.TheWPFDirectory.com site launched! Latest Tech Blog Post: You got to see this - Seadragon and Photosynth!
-
Paul Conrad wrote:
Now that's a notation I have not used in a long, long, long time
I Float between the two, but i've lately i've been trying to double my use of hungarian notation ;)
Sometimes I'll do Hungarian out of shear laziness :->
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
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:
If you change the variable's type, it all of a sudden invalidates the name of the variable.
This is a Good Thing. If you change the type of a variable, it's a good idea to look at every place the variable is used, to make sure the code using it is still correct.
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
-
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. ------As mentioned at some point in this thread, a decent IDE will tell you a type anyway so you do not need to include this information in the variable name. Also I tend to find that if all variable names look the same, for example start with str or mint then I struggle to read the code.
-
Yes. Using non-generic collections is a horrific practice in any application that has access to the generic ones.
Quite right - after having used C++/STL for more years than I care to remember, I was unwilling to look at .NET at all until 2.0. And with lambdas and Linq in 3.0, C# is looking pretty good...
-
Here's the trick: read the code out loud: if it comes out sounding like a bad foreign accent (or, Yoda), then you need to work on the names... ;)
----
I don't care what you consider witty, but at least I do not blather on posting nonsense like Jim Crafton.
-- Stringcheese, humbled by Crafton's ability to string together multiple sentences
Careful - too far down that road and you'll turn into the Grand Magus :-)
-
Vikram A Punathambekar wrote:
I think camelCase is way better for method names. [ducks]
Actually, after having spent so much time in Java over the past few quarters at school, camelCase method names feel more natural for me. I still have to think about it when I'm writing C# again.
I *have* done some Java, but it wasn't a big deal - one paper at college and one Java app maintenance at my previous company. I've written FAR more C# code than Java, but for some strange reason, camelCase feels more natural for method names. I actually dislike PascalCase for method names!
Cheers, Vıkram.
After all is said and done, much is said and little is done.
