|
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
|
|
|
|
|
John R. Shaw wrote:
I have one of the old 8088 (I think) suitcases
The old first Compaq? The 15kg machine? 
Keep them all! I regret that I sold my C64!
|
|
|
|
|
|
We use Hungarian notation, and I have no problem with that, however there are so many possible permutations that you have to simplify it a bit. I mean I just use small n for *all* numbers, otherwise it gets ridiculously complicated (unsigned int, unsigned long, DWORD, INT64, ... the list is endless). Also, things like lpsz (a long pointer to a zero terminated charcter array) are really silly because all pointers are now long
|
|
|
|
|
By doing this, I think that you miss one of the things that HN is really good at: telling apart similar types. I mean, in 99% of the cases I can tell if a variable is a number or a string from the context and/or the variable name. However, to tell an int from an unsigned int, in most cases I would have to look at the declaration.
|
|
|
|
|
For this question, a radiobutton forced decision is not adequate. I bet that almost everyone uses a certain mix of the styles, and probably noone of the 'Hungarian' voters use the hingatian style in all its glory.
We have a company coding style guide, and this uses a mix of all variations:
locals in 'camel back',
members prefixed with a 'm_', globals prefixed with a 'g_',
pointers are REQUIRED to have a 'p'-prefix,
method names are verbs and Pascal style,
etc...
So I really would have voted all of the choices.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
jhwurmbach wrote:
a radiobutton forced decision is not adequate
Correct. This poll is silly.
The Java convention is "camel" for variable names, "pascal" for class names. In other words, classes start with capital letters.
In my experience, only people used to MFC use "hungarian". Underscores instead of capitalization tend to be used more often by people used to the STL. But...
jhwurmbach wrote:
I bet that almost everyone uses a certain mix of the styles
Yes, especially people that have used more than one language. So again, I agree this poll is silly.
Whatever happended to using variable names that actually make sense?
|
|
|
|
|
... That I do not want to make the language more poor by adding type informations
to my identifier.
Instead, I like to use simple prefixes:
a for attributes
p for method arguments (parameters)
C for class
k for constants
g for globals (like static class attributes)
For me, having a "num" "str" "hwnd" prefixes defeats the purpose of C++ types
I sometimes use T for typedefs or simple structures.
I always use C for class names
I find code much more easy to read this way - except that I am alone to use these
conventions 
For local "stack" variables, I use lowercase_underscore_separated identifiers.
When I deal with "complex" expressions, I tend to add a named variable to simplify it.
Sometimes, I disgress by naming local variables in such a way as to repeat it's type.
When I do that, the context usually prooves me right.
...
...
CTracerUtility& tracer = CTracerUtility::Singleton();
...
...
I must confess that my projects (usually huge ones) often contains huge amounts of classes.
I try to write my code with the feeling that even if it is trivial, I must be able to
instantly recognize the intent of the code 6,12 or 18 months later.
Using such a notation helps me a lot. (I write a LOT of code...)
|
|
|
|
|
I have to say, not being a C++er, that that a, p, C, k, g idea is very confusing. Not intuitive at all 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?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
