|
I liked that quotation from the previous link:
"and of no relevance at all in a type-safe object-oriented language like C++."
(Talking about the hungarian notation)
|
|
|
|
|
This from the people who gave us the export keyword. "Mom, can we add export to the language, Billy next door has export. The kids at school make fun of me for not having export."
I actually have a LOT of respect for Sutter (sp?). I don't agree with a lot of the stuff he says but he does his research and has no problem telling people when he is wrong (i.e. the export keyword).
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Michael Dunn wrote:
when used properly, they make code easier to read
But even that simple statement is debatable. It depends what you mean by "properly": strictly (always) or when relevant (only when confusion may arise)?
|
|
|
|
|
I couldn't agree more. Hungarian notation has helped our shop weed out logical errors such as:
int cycles = 0;
...
if (cycles)
...;
which are easy to find when we use Hungarian notation:
int nCycles = 0;
...
if (nCycles)
...;
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
The problem here is a bad name for cycles. In my workplace, plural nouns must denote containers/arrays, so it would mean that cycles is a vector of cycle objects. I would call it cycleCount, and then you don't need Hungarian, and it is more descriptive.
|
|
|
|
|
|
Totally agree. If people would have appropriate names for variables, there is little to no need for hungarian notation.
what does "strFirstName" buy me that
"FirstName" does not.
John K.
|
|
|
|
|
Actually
strFirstName tells me its a string objects
whereas
szFirstName tells me its a char array.
I know its small, but these little things help.
Also, FirstName is going to be a string object or char array, fine
but consistancy in convention is more important than the convention itself.
So if you are going to use str..., sz... n... d... whatever, then you should use it everywhere, even in FirstName.
Jules
|
|
|
|
|
Julien wrote:
Actually
strFirstName tells me its a string objects
whereas
szFirstName tells me its a char array.
I know its small, but these little things help.
Have you ever taken the time to hover you mouse over a variable in the IDE, I think the type is very clear...
I code to make money not to attain some form of higher enlightenment, and use every tool made available to me to make this process easier.
|
|
|
|
|
Hey J.B
I did say 'small'.
I don't know why you think I'm some code-monk looking for enlightenment. I think you'll find quite a few of the developers here code 'to make money', perhaps we should have a poll for this?
I use mouse over function also for more complex types that I don't have control over. I was just saying I think it helps.
Julien.
|
|
|
|
|
sounds like a good poll.
I come across many different standards for coding conventions, and sometimes absolutely none or several in one project (just look at some of my code on a bad day  ) So far the best as far as consistency and implementation came from a Xtreme programming shop (not that I follow that mantra either, but recoignise the good elements) using a variation camel case and explicit naming, no shortened words, that are meaningful to the application. These standards were enforced throughout the company right down to the number of spaces between line items... And did it look good  , was easy to read and usually made sense.
Basically I do what I am told...
|
|
|
|
|
FirstName is obvious but how about blnResult, lngResult or (preferably NOT) strResult?
|
|
|
|
|
Well, it isn't an unsigned type either, so maybe you REALLY REALLY meant a logic statement like this:
if( nCycles > 0 )
instead of
if (nCycles != 0 )
since
if( nCycles )
and
if( nCycles != 0 )
get you the same result for a signed variable, don't they?
All along it maybe should have been:
unsigned int nCycles = 0;
...
if( nCycles > 0 )
...
Now THAT is a correction to a potentially serious problem!
|
|
|
|
|
pI vAgree nMICHAEL, pIt vDoes avNot vMatter cWhether pIt vIs nEnglish cOr nSpanish, pEveryone vUnderstands adMy nWriting aA nLot aaBetter avWhen pI vUse adSome nSort ppOf adHungarian nNotation. 
nRegards,
nAlvaro
Legend:
n = noun
v = verb
a = article
ad = adjective
av = adverb
p = pronoun
pp = preposition
i = interjection
c = conjunction
He who laughs last, thinks slowest.
|
|
|
|
|
pI vKnew pYou'd vSee aThe nLight! CP nPosts vAre adSo adMuch adEasier vTo vRead ppIn adHungarian nNotation!
/ravi
Let's put "civil" back in "civilization"
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Actually, this is the best argument I've seen for Hungarian notation in this entire thread. I recently had the experience of working on code originally written by a German company. Some of the variable names did not have any meaning for me. Type notation would have at least made their content clear. The keywords (and their abbreviations) are pretty well fixed, whereas variable names are not.
>>>-----> MikeO
|
|
|
|
|
That's comparable with writing your code like this:
kwif op( varCount op== num5 op)<br />
funDoThis op( lit"Hello" op) ;
I don't think anyone who advocate Hungarian Notation would prefer this kind of language. And there your argument falls.
But to continue your comparisons with the English language:
If you would ask a lawyer, he would probably like to see some way in which to make it easier to interpret the language. I can present you sentences that can be interpreted in three different ways depending on the context. I'm not saying that your suggestion would help much here, but something that would give the kind of help that HN gives us programmers I think would be appreciated.
In Spanish (and probably other languages) they have the problem that two words that are spelled the same way mean different things. What they have done here is to put accents on some vowels to diferentiate the words -- even though you in most cases can tell what word it is from the context. Not the same as HN, but it's the same kind of "unnecessary" information added only to clarify.
|
|
|
|
|
My reply to Michael was meant more as a joke than an argument.
I'm aware of Hungarian notation's pros and cons, and I've chosen to get away from it because I believe the cons outweigh the pros. I used Hungarian notation for many years (and still do when maintaining old code), but was forced to stop using it a couple of years ago when I started doing Java. To my surprise, I began to like the way my code looked without the prefixes in all my variables. It was just easier to read.
I guess it boils down to personal preference. What do you like better?
void RepeatName(string strName, int nTimes, bool bInCaps)
{
if (bInCaps)
strName = strName.ToUpper();
for (int nTime = 0; nTime < nTimes; nTime++)
Print(strName);
}
or
void RepeatName(string name, int times, bool inCaps)
{
if (inCaps)
name = name.ToUpper();
for (int i = 0; i < times; i++)
Print(name);
}
Both pieces of code are fine, but I prefer the second version. Also, when looking at this method's signature via Intellisense, I prefer to see the names of the parameters without the prefixes, which just get in the way IMHO.
Regards,
Alvaro
He who laughs last, thinks slowest.
|
|
|
|
|
For basic types (int/char/float/etc.) or very common classes (string) it works, at least to the extent that i don't *mind* reading code that uses it.
But it goes to hell once people start making up prefixes on the fly to use for each new class they create... Or just prefix all objects with obj...  
A servant to formulaic ways.
Shog9
|
|
|
|
|
Michael Dunn wrote:
they make code easier to read and easier to understand
This is where I disagree. I would be interested in seeing a concrete example of this, because in my entire programming career, I have NEVER seen a piece of code where Hungarian notation made it easier to read or less prone to bugs, and NEVER seen a piece of code that is not written with Hungarian, but that Hungarian made it more readable.
99% of the time you shold be able to tell what a variable is and does based on its name and context. The other 1% of the time, use IntelliSense to figure it out, or have the header open in another window so you can see it directly.
Hungarian causes big problems when a variable type changes... then you either have to go through and search/replace all the types, or, more commonly, leave the old Hungarian but use a new type, thus making the previxes irrelevant.
Also, some prefixes just don't make sense. It took me forever to figure out what "lpsz" meant.
So, in my experience, Hungarian just adds an extra layer of complexity to the code that is unnecessary.
[EDIT] Actually, I did come up with an example of where a type prefix makes sense, see my post above for details.[/EDIT]
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Sort of like "empty" and "clear" in STL. Yeah, you know EXACTLY which one is the test and which one is the "RemoveAll" function.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Yeah, no kidding. I always have to stop and think to make sure I'm using the right one.
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
pronI contrcan't vdisagree advmore. How can that be easier to read. Besides hungarian notation negates abstraction. Code chunks should be kept small enough that you can just glance up if you happen to forget what the type of a variable is. Although it probably doesn't matter much anymore, it's better to keep autos defined close to usage anyways.
|
|
|
|
|
Sounds like calling your son 'sonJohn', your dog 'dogBlacky', your car 'carFord' and your wife 'wifeSuzy' (or something similar). Does that make it easier to understand your wife?
No, seriously. Good variables should hide the implementation. If I want to use 'strCustomerName' I'm not interested that it's a string. Maybe it was a string in the past, but now its changed to a class.
Or the member 'nOrderedQuantity' of a class 'Order' was once an integer value (because the application only managed book sales), but now it is a floating point value (because the app now also manages the sales of something that is sold in e.g. gallons). Do you change the data member's name then?
Enjoy life, this is not a rehearsal !!!
|
|
|
|
|
I'm the one who is absolutely stuck with the hungarian notation along the past decade or so. However, I would love to know how hungarian notation could be possibly extended to address new controls and objects under the new framework.
Cheers,
Mehdi Mousavi - Software Architect [ http://mehdi.biz ]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
