|
|
Philosophically, we use the Pascal convention but with a small selection of acceptable prefixes which effectively convert us to Camel case.
We use mostly English prefixes such as "the" (where broadly speaking we know what's in the variable) and "a" (where we don't, because it's local to a loop of some sort). Other acceptable prefixes are "in" and "out".
I think I would prefer that we use "the" only for member variables and don't use a prefix for local variables, unless it's set in a loop and therefore warrants using "a". I feel that "the" is rather over-used in our code - but otherwise, it seems to work fairly well and generally improves code readability.
Gavin Greig
"Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye."
Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles.
|
|
|
|
|
|
|
|
That must be one of the most confusing and awfully written articles I have ever read.
If it's purpose is to point out that Hungarian notation is confusing and useless, then it should heal thyself, physician.
(I realise it was trying to be a clever dick, but it was too clever for it's own clogs IMO)
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
