|
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 ]
|
|
|
|
|
IMO it made sense when almost every type was constructed of a limited set of base types, and the language (C, mind you) does not provide the necessary type checks. or OO programming, they are not expressive enough yet to bulky.
"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."
mlog || Agile Programming | doxygen
|
|
|
|
|
I use Hungarian notation with prefixes, but I must admit that it happened with no special reason... I started because copying and pasting sample code found here and there, these notations where included inside... Then I got used to.
I think that it's really difficult to discuss of details like this because they belongs to a personal point of view of a coding style.
Even identations, I've get used to the class-wizard style because... it was so "impersonal" and I code more for others than for me.
At the end I'm very severe on the style that I use, but I don't bother of how others code - if I'm in trouble, I launch this macro[^].
Probably my point of view depends on the fact that I work alone or in a small group. Maybe in some programming groups the coding style is imposed by the programmer leader and there is no other way to write in a different way.
|
|
|
|
|
John A. Johnson wrote:
At the end I'm very severe on the style that I use, but I don't bother of how others code - if I'm in trouble, I launch this macro[^].
Who doesn't love Alvaro's cool little macro.? I sure do seem to use it a lot too.
Tell me can I rate his article twice?
|
|
|
|
|
I use Hungarian notation with prefixes too, but I strongly believe that when working with a group there should be only a standarized point of view, not personals, because groups change, but the code still remains there.
When looking someone else's code and you see somewhere a variable named m_pCurrentObj, and pCurrentObj where whould you look first to find the declaration? I would suppose that the first one is a member variable (pointer) and look in the class declaration to find it and the second one be a local variable and look in the function. But if you were unsure that the person who wrote the code used some naming convention, where whould you whould look for a variable named "currentobj".
How many of us have checked on MSDN for code samples and documentation. What whould happen if every developer that has posted his code there used his own personal naming method. How much easy could anyone use the samples and check his code against the articles?
My opinion is that since naming conventions are for humans, they should be used in such a way to make everybody's life (in a group at least) easier. If it was for computers, names with only one letter and numbers such as A1234, A4562, A3468796 are better than enough, but are such names acceptable?
What meaning whould a class declaration have like this:
<br />
typedef char* A23423;<br />
<br />
class A457887665 {<br />
public:<br />
A457887665() {A8768764=0;}<br />
~A457887665() {}<br />
void A7456376(A23423 A9874) {A45345 = A9874;}<br />
protected:<br />
int A8768764;<br />
A23423 A45345;<br />
};<br />
...Plug & Pray... 
|
|
|
|
|
Yes you must be right.
I get use to these conventions because I feel more confortable and I'm more productive.
But it happens that I'm a consulent. Seems that I have passed all my time converting VB programmers to C++ (OOP), and what makes me happy is that they monkey my coding way without asking too much.
Sometimes happen that I have to work with very well experted computer programmes, but I don't like to waste time talking of the "sex of the angels" (=in my country is a way to say... waste time talking about things that can have different opinions). I'm normally able to interact with them, and, because they are experted, what happens is that - coding conventions apart - both of us grow a lot.
Only one question... what's the meaning of the A8768764 property in your class... it's protected and there are no methods that use it (exept for the starting initialization! You must well comment your code!  (kidding)
|
|
|
|
|
John A. Johnson wrote:
meaning of the A8768764 property in your class
The class is a simplified cropped example of a String class I had used, so no particular use in this specific class. Just on more line copied I guess...
I just included it in the post as a small simple example to show that what can be good enough for a computer is unacceptable for the developer. The compiler will produce the same code no matter if you write comments or not, no matter if you use names like those or more human readable names.
It would take (to me at least) more time to understand and use a class like that in my code, than a similar class like the following:
typedef char* LPCHARDATA;<br />
<br />
class CCharData {<br />
public:<br />
CCharData() {m_nLength=0;}<br />
~CCharData() {}<br />
void SetStringData(LPCHARDATA lpszData) {m_lpszData = lpszData;}<br />
protected:<br />
int m_nLength;<br />
LPCHARDATA m_lpszData;<br />
};<br />
...Plug & Pray...
|
|
|
|
|
Dimitris Vassiliades wrote:
How many of us have checked on MSDN for code samples and documentation. What whould happen if every developer that has posted his code there used his own personal naming method.
They do sometimes. Especially structures... sometimes they have the Hungarian prefixes, sometimes they don't. Same with parameters (although that doesn't matter as much.)
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
Old windows programer, old habits (me not you).
I normaly use warts to remind me of the data type being used. Lately I've started to get away from the generic n, since it does not tell me if it is an int, long, short, unsigned, etc... and I like to look at the name and know what type it is. Example: NumberOfItems does not tell me if I am dealing with a signed or unsigned variable which is very inmportant in determining how it can be used. nNumberOfItems same problem.
Some people consider it useless; but next year when I need to modify the code, I will probably not need to spend as much time figuring the data types being used.
INTP
|
|
|
|
|
I don't know if you saw my bio... I've deleted my birth date! I know it's childish: 11 may 1964 and I started working in informatics when I was 17 (it was a hobby when I was at school)... remember the C64? The Pet? The Datageneral? The PDP11? The VAX? Coding in Fortran 4? Then 77? then discovered Pascal (turbo)?
My God!
What is really funny is that I'm studing C# with the same interest of the first MS Basic (and that keeps me young!).
My habits are really old, a sample: when I start with a new IDE, I study all the short-keys, mouse make cramps on my right hand... 
For the formatting style and the naming conventions, I follow what I see in the projects they give me, when I can start from scrach I use the things I prefer for my datatypes things like:
n int (I don't use short)
l long
u unsigned int
ch char
by unsigned char
sz all kind of strings, CString, base_string, char pointers, or char arrays
b boolean
dt date (75% of cases COleDateTime)
f float
df double (it's because I keep the "f" when I change the variable from float to double)
p pointer
v variant or COleVariant
m_ member properties
C classes prefix
I get crazy with the controls... but actually I do things like:
pt point
rc rect
size size
lb listbox
lc list control
tc tree control
ed edit
bt button
... but each time I need a different class, I panic thinking to invent a new prefix.
I have to correct my habits for currency, acrually I use n, it was ok when my nation currency was LIRA (without decimals), but now that I work with EURO and other currencies I must adapt to cy but I forget all the time...
I know that other have different variant types... for sample I like to see that there are people that use i for integer, I'm confused when they use rc for booleans (it's because I use the same for rect's).
|
|
|
|
|
Well what do you know your almost as old as me (12/14/1960)!
Remember the C64? I still have one and 8088, 286, 386, etc... I have one of the old 8088 (I think) suitcases (portabel PC) sitting in the courner waiting for me to open it (one of these years) in order to find out why the keyboard is not working (I supect broken wire). I've never worked on any of the big boys though.
Your naming convension looks very much like mine but I use cs for CString and sz for noromal C-style stings.
Well time to get back to work.
Have fun!
INTP
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
