 Hungarian Notation
started 3/23/2003; 2:09:12 AM - last post 3/24/2003; 11:16:50 AM
|
|
Dan Shappir - Hungarian Notation 
3/23/2003; 2:09:12 AM (reads: 2350, responses: 6)
|
|
| Hungarian Notation |
|
I think people who think Hungarian makes code "hard to read" have never learned to read Hungarian notation. Heck, I think Greek is hard to read. But if you actually take the time to learn it, it makes code that much MORE readable. You know so much more about what a variable is by looking at it.
I would contend that any type of consistent notation is better than none. The interesting issues here IMO are when type annotation gets in the way of abstraction and differences between notation strategies for distinct PLs.
Posted to Software-Eng by Dan Shappir on 3/23/03; 2:09:59 AM
|
|
|
|
Ehud Lamm - Re: Hungarian Notation
3/23/2003; 2:18:18 AM (reads: 1450, responses: 0)
|
|
|
Well, the obvious example is strings. When the language has string types that are distinct from char pointers, you don't really need Hungarian. In C, however, a char* may point to a buffer (remember we have weak typing), or to a null terminated string. The language isn't expressive enough, so by looking at the declaration of a variable it's hard to tell. Using Hungarian helps overcome (or mitigate) such problems.
|
|
Dan Shappir - Re: Hungarian Notation
3/23/2003; 2:25:40 AM (reads: 1451, responses: 0)
|
|
For my C++ work I use a subset of HN. For example I place a capital C in front of my class names (e.g. CSomething) and a p in front of pointers (e.g. pSomething), though I intentionally do not differentiate between basic pointers and smart pointers. I find it useful to prefix member variables with m_ and static member variables with s_.
OTOH I try to not get stuck on the explicit type, for example I won't name an integer type variable iSomething but rather cSomething if its a counter or nSomething for simply identifing it as a number. Likewise with sSomething for a generazlied string object.
Finally I do tend to name simple, localized index variables i or j (shades of FORTRAN ;-) I never go beyond k because it gets confusing and l looks too much like 1.
|
|
Andrei Formiga - Re: Hungarian Notation
3/23/2003; 7:53:10 AM (reads: 1410, responses: 0)
|
|
|
A different oppinion on Hungarian notation, from a C++ perspective:
Conversations: Hungarian wartHogs by Jim Hyslop and Herb Sutter.
I think the usefulness of Hungarian notation decreases if you have good development tools, where it's possible, for example, to point the mouse to some identifier and be informed of its declaration. Another interesting experiment in this vein is colorForth.
|
|
David B. Wildgoose - Re: Hungarian Notation
3/23/2003; 11:40:20 PM (reads: 1325, responses: 2)
|
|
|
I have used a limited form of Hungarian notation for years, and have found it very useful. For example, the language I work in allows parameters to be "Input", (no external effect), "Output" (returning values but no initialisation), and "Input-Output" (incoming values and new values exported when the routine ends). I preface my parameter variables with "i_", "o_", or "io_" accordingly. This is extremely useful - it is important to know what "side-effects" a routine can cause, and which variables to watch.
But the "full" version is worthless in my opinion.
The first company I worked at after graduating insisted that the types of all variables be included as part of their name. But the various "prefixes" attached to a name along with a maximum mandated variable length just meant that the "real" name was truncated and ambiguous.
This was just pointless wase of time in my opinion - a good variable name and the context gave more information.
Furthermore, if the type were to change slightly, every variable needed to be renamed when all that was really necessary was a single line change in the declaration file. This latter difficulty meant that sometimes such changes were ignored, which meant that you couldn't really trust the notation/name in any event, and so the whole exercise was nothing but pointless obfuscation.
|
|
Ehud Lamm - Re: Hungarian Notation
3/24/2003; 12:48:28 AM (reads: 1377, responses: 1)
|
|
|
Funny thing: I am marking exams, and I asked about making programs flexible. Just a minute before reading your message I read an answer that said the strong typing (+information hiding) helps flexibility, because when the details of the type change, you change the type, and recompile, and the change is invisible to the outside world...
|
|
Dan Shappir - Re: Hungarian Notation
3/24/2003; 11:16:50 AM (reads: 1356, responses: 0)
|
|
|
And if you make proper use of interfaces you may not even need to recompile, you may not even need to relink. Just replacing a DLL / shared object might be enough. Now that is flexibility.
I also make sure to place object definition as close as possible to the object use. Aside from making the code more efficient, it makes the code easier to understand when you see the variable type in the same context as its usage.
|
|
|
|