|
O.K. What's so bad about Hungarian Notation?
<This is not a troll>
I seriously want to know the pro's and cons. I currently use it!
Mike grace
Wednesday, February 4, 2004
g_pstrI m_lDon't lpstrReally g_lpszKnow.
Wednesday, February 4, 2004
The big problem I see is just gets in the way of readability. It seems OK for languages that are not strongly typed, otherwise is just redundant.
Bill Rushmore
Wednesday, February 4, 2004
See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp for the definitive reference on it.
It's terrible. Principally, it encourages you to think that all you have to do in order to select a variable name is to figure out a mnemonic for its type, and not to bother mentioning what that
particular variable *means*. Its goal is stated like this: "A good yardstick for choosing a name is to try to imagine that there is an extraordinary reward for two programmers if they can independently come up with the same program text for the same problem."
Frankly, I think that's a terrible goal, and I think the function he shows (near the bottom) proves the badness of the idea: look at it, and tell me what the function really *does*.
(Oh, right it returns a pointer to a struct SY (wait, I mean a Psy), given an sz. But what's in that input string? What's the corresponding SY structure?). Now imagine a large-scale program where every function looks like this, and imagine trying to figure out what happens in that program, so that you can explain it to yourself or someone else.
I could go on, but I'd better stop.
Exception guy
Wednesday, February 4, 2004
I had better look up strongly typed datasets then.
I usually use strFirstName for a string, bAnswer for boolean etc..
Mike grace
Wednesday, February 4, 2004
I used to use HN when I was doing C programming. It was easy, for example, to pass in a pointer to an int and then treat it as an int and things would break. C++ made it harder to do that without wicked casting and the compiler catches most of those kind of errors. So, I agree with the previous poster that it's now redundant.
Also, modern IDEs allow you to hover the cursor over a variable and show you the variable's definition.
Bathmophobic skier
Wednesday, February 4, 2004
As long as the variable name is descriptive and self-documenting I don't care what it is called, but now that we have strongly-typed variable names I think the need for Hungarian Notation is redundant.
It would be like prefixing all of your relational table names with 'tbl' and your column names with 'col'. It provides no meaningful information and is basically a waste of typing.
MR
Wednesday, February 4, 2004
I used to work on a project where all the table names were prefixed by 'tbl'...
A non y mous
Wednesday, February 4, 2004
The guy who invented Hungarian Notation is a billionaire. Therefore it must be good. Unless you're a socialist. Then it's bad.
magoo
Wednesday, February 4, 2004
I use hungarian-like notation for controls.
For example, every button starts with b, every listview starts with l, etc.
Example:
bNext - the button labelled Next
lDisabledItems - the listview containing disabled items
This is very handy.
MX
Wednesday, February 4, 2004
Not Col, but I do always tell people that I am teaching databases (mostly Access) to to prefix their tables with tbl_ and their queries with qry_
When you have people that know what they are doing, it is not a biggie, but doing this forces students to decide whether they are using tables or queries. You would be amazed how many people try and input data into a query.
The concept that a query/view IS NOT a table is (I find) taught best when someone has to make a concious decision every time about whether they are using a query or a table.
While Access has come a long way, it is useful to have tbl_ and qry_ explicitly stated. If you edit a form, and show a list of the fields available, all you have is a name, with no indication of whether the data source is a table or query. Hell, even trying to change the data source in the form designer view confronts you with a list of queries and tables with no disctinction between the two.
There are no hard and fast rules.
Tapiwa
Wednesday, February 4, 2004
My wife is Hungarian, so Hungarian Notation must be a good thing.
"I used to work on a project where all the table names were prefixed by 'tbl'..."
I'm currently working on several projects like that. They're mine. It's pretty easy to keep tables and queries separate, because tables start with tbl and queries start with qry. Strings with str, ints with int, longs with lng... However, I don't put scope in the name, because I think that's where the unreadability starts to come in.
Kyralessa
Wednesday, February 4, 2004
> I used to work on a project where all the table names were prefixed by 'tbl'...
I used to work on a project where the table and field names were not prefixed by anything
When we ported between databases (which happened a lot), we frequently had collisions between our meaningful field/table names, and reserved words in the particular database.
S. Tanna
Wednesday, February 4, 2004
Having a standard naming convention for different data types is so useful that it should be part of the language! We should petition Microsoft/Borland/etc. to change their compilers so that all variables beginning with i,j,k MUST be integers; all variables beginning with x,y are doubles; etc.
Also, writing comments should be made easier. Instead of having blocks like this:
/***
* This is
* a long
* comment
***/
Let's skip the first and last lines, and just mandate that any line that begins with an asterik is a comment.
I have many other useful suggestions, too.
Troll 77
Wednesday, February 4, 2004
Whatever notation, you just have to be intelligent about it, and it's never effortless. As long as your team understand that and strive to hold up to the coding guideline, code will be (to the extent possible) readible.
Li-fan Chen
Wednesday, February 4, 2004
>> "I have many other useful suggestions, too."
Useful to who? Sure as hell ain't useful to me.
Wednesday, February 4, 2004
I too have suffered the process of trying to come up with a naming convention. The first problem you come to is that if there are 3 char codes for different classes then all your user defined classes need 3 char codes and with 200 classes this is going to end up unmemorisable, ugly and meaningless.
So my personal thing? I'm programming in vb.net and I use the standard codes for the value types (int,str,lng,dbl,bln etc.), well-known controls get their standard codes (lvw,lvi,tvw,frm etc).
Apart from that I've developed this strange habit of putting a 'z' in front of any variable that doesn't fall into one of the above categories. It makes it dead easy to spot the variables when scanning through some code.
Enum values get an 'e' at the beginning
In terms of scope I prefix parameters with an 'r' (not sure where this comes from), class-wide variables with an 'm' and global variables with a 'g'.
Now most of you are probably going to think I'm a tosser, and you may of course be right!, but it generally works for me.
Every so often I think about changing it but then I would have to change everything I've already done or make the code inconsistent, so for now it stays.
I look forward to discovering a better way!
gwyn
Wednesday, February 4, 2004
"It was easy, for example, to pass in a pointer to an int and then treat it as an int and things would break."
What? Are you not compiling with warnings, or are you ignoring the warnings? To paraphrase something i read a long time ago, turn the "Warnings" knob all the way up until it breaks off, then bury the knob and tear up the map to the place where you buried it.
Some people, when they get a compiler warning, stick a cast in there to make it go away. That's like disconnecting your "check engine" light when it goes on.
Mike Schiraldi
Wednesday, February 4, 2004
Horses for courses.
If you're programming C++/MFC you're better sticking to hungarian for consistency with the class library & Win32 API declarations.
If you're programming Java or C#, don't touch hungarian and use camelCase and PascalCase to indicate variable scope.
VB6 being case-insensitive brings it's own problems: camelCase and PascalCase doesn't work well - if you create a variable MyVar the IDE will annoyingly rename other unrelated myVar variables to MyVar. So here again I normally stick to some kind of hungarian. (Since VB doesn't have pointers you don't have the issue of the excessively long prefixes beginning lp)
Joe
Wednesday, February 4, 2004
Case sensivity is a good thing?
yuk-yuk-fuckety-yuk
gwyn
Wednesday, February 4, 2004
"I used to work on a project where all the table names were prefixed by 'tbl'..."
There is a good reason for that: name collision. When you have tens of thousands of objects in your database it makes sense to create different 'namespaces' for tables, primary keys, foreign keys, stored procedures, functions etc. Never happened to you to spend half a day to see why you can't add that damn PK? Ohh, you mean there is FK somewhere there among those 2000 FKs with the same damn name?
coresi
Wednesday, February 4, 2004
Some number of years ago, I read Simonyi's original thesis on his proposed notation. I can't find it in a simple Google search anymore, but I think the basic concept is very solid.
The original idea was to add a prefix to a variable to give you more specific information about the type of the variable than what you'd get from the declaration. This allows you to distinguish between a position and a count, for example, even when they both have "int" type.
Somewhere along the way at Microsoft, this got perverted into "let's duplicate the type declaration at the front of the variable", which really *is* worthless in any language with a strong type system.
A lot of people, when they see "Hungarian Notation", are thinking of the Microsoft-style:
char *lpszFoo;
where the prefix serves no purpose other than to make the variable longer and harder to type.
Whether the "prefix as type qualifier" version is really useful is more a matter of style. Having a consistent, concise notation for "this is a count, this is a size" is at least potentially more clear than everybody on the project using different conventions, for example:
count_words, word_count, num_words,nWords, etc...
Having said that, I've never used any kind of Hungarian Notation in a real project. I usually find that it's not too hard to keep track of what's in a variable. If you can't read and understand the code at a glance, it probably needs more comments (or a re-write).
-Mark
Mark Bessey
Wednesday, February 4, 2004
I agree with MX, variants of hungarian notation for gui items is very helpful. Especially if you have many different controls doing similar functions: lblRun, mnuRun, bRun, etc. In my mind, that improves readability. Encoding wickedly long type definitions into every variable does not.
John Wilson
Wednesday, February 4, 2004
How about the "m_" prefixes for member variables? What do y'all think of those?
Oren
Wednesday, February 4, 2004
I used Hungarian notation when I was coding in VB6, but gave it up when I went to VB.Net/C#. At first I thought that my variables looked rather naked without all those prefixes, but realized that it resulted in much cleaner code. (However I still use an "m_" or "_" for non-local variables, of course.)
If you're using C# or VB.Net, there just isn't much need for Hungarian notation since Visual Studio will catch inadvertent casting errors. There's a good debate about the pros and cons of Hungarian notation in this old newsgroup thread:
http://makeashorterlink.com/?M2C754C47
Robert Jacobson
Wednesday, February 4, 2004
Oren asked "How about the "m_" prefixes for member variables? What do y'all think of those?"
A trailing underscore ("member_") is the one true way. (The "m_" gets pronounced in the name and in your head, and so lengthens the name in both speech and thought, which slows down speech and complicates thought).
Exception guy
Wednesday, February 4, 2004
Actually, I've been using a trailing _ for member variables, so I end up with a series of declarations:
private int _superCount;
private string _someString;
It lets me definitely differentiate between private members, and it also has the advantage of grouping those types of members together in my IDE's dropdown list of class members, properties and functions.
John Christensen
Wednesday, February 4, 2004
Gah. *Preceding* underscore, not trailing underscore.
John Christensen
Wednesday, February 4, 2004
I prefix web and gui controls with their type because, as another poster says, you often have a group of controls that do the same thing.
tbEmplID, btnLookupEmployee, lblEmplID
The key rules I follow to prevent Hungarian Hell are 1) never use prefixes on class properties (except "_" for private) or function names
2) *NEVER* try to include more than one piece of information in a prefix.
I like prefixing UI controls because it works in-hand with intellisense. I usually know what type of an object I want to work with, even if I can't remember the name exactly. I type "btn" and hit CTRL-Space and I get a list of all buttons in scope.
Richard P
Wednesday, February 4, 2004
> Actually, I've been using a trailing _ for member variables, so I end up with a series of declarations:
I'm sure that's not too wise if you were using C/C++. Detailed reasons left as exercise for the reader.
On the main point:
I'm not a huge fan of MS style crazy hungarian
But a small amount may be useful when reading code.
For example,
If I'm reading code which process say an array of say folders
At a glance if I see
strCurrentFolder or szCurrentFolder
I know this is the name of the current of folder as a string without referring back to the declaration.
However if I see
CurrentFolder
It's not immediately obvious if this is an index to the current item in the folder array, the name of the current folder as a string, etc.,
I have to refer back to the declaration to know
Yes, I realize somebody could write
CurrentFolderIndex
CurrentFolderName
But my experience is they generally don't
S. Tanna
Wednesday, February 4, 2004
I've been brainwashed. I had a job that specified it in their style guide, so I find myself using it even though I'm not that fond of it, other than for GUI controls. I especially hate the "m_". There's something about the underscore that really slows me down when I'm typing.
One thing I've noticed, though. NEVER use Hungarian notation for academic work. I'm 8 classes into a CS program and so far my tally is 7 prof's strongly anti-MS and 1 prof pro-MS (he develops games). I made the mistake of using it in one of my assignments and actually got style points knocked off. I'm not kidding! If I'd worn a "Vote Bush" t-shirt that day, I probably would have been expelled.
Student A
Wednesday, February 4, 2004
If you read Simonyi's white papers for his new, current company (I don't recall the URL, I'm sure someone here knows it offhand) he doesn't quite say that Hungarian Notation is obsolete and no-longer needed, but he comes close.
It was a good idea, for the time. Languages and IDEs have moved beyond the need for it, so let it go.
Mr. Fancypants
Wednesday, February 4, 2004
Back in the old days, we used to have long discussions about the best way about how to represent a useful name in 6 characters, since two of the max 8 characters were mandated to represent the module. Now THAT was a challenge.
David Hurst
Wednesday, February 4, 2004
If you have name collision with database objects then you have a bad naming scheme.
MR
Wednesday, February 4, 2004
That's deep, man.
Kyralessa
Wednesday, February 4, 2004
I also believe all variable names should be prefixed with an indicator as to which language is being used. Thus jname for Java, cname for C and so on.
I also believe every programmer should start work at 9 am and wear crisply ironed shirts. A tie is optional.
Because I'm very tolerant, I, unlike others, do not insist that you attend the morning calisthenics session. However we do record attendances.
So, please enjoy yourselves. You will find we are a tolerant, fun loving workplace.
We know best
Wednesday, February 4, 2004
To answer my own question (about "m_ prefix"): I don't use it. I agree that it makes the name more complicated to pronounce (even in your head), so out it goes. But in addition to that, I don't think the variable name *can* indicate all the possible permutations. For example, if I was going to place metadata into the name then I'd like to know:
- Member variable, local variable or parameter?
- If a parameter, is it In, Out, or In/Out?
- If a member variable, is it public/private/protected?
I use variable names only to describe the variable's purpose, and I use the IDE to show me meta-information about the variables.
Oren
Wednesday, February 4, 2004
[ http://mindprod.com/unmainnaming.html ], especially items 27-30, are a good reference. In fact, the entire "unmaintable code" document is a good reference - read it if you haven't yet, at [ http://mindprod.com/unmain.html ]
And slightly more serious, is Rob Pike's wonderful essay at [ http://www.lysator.liu.se/c/pikestyle.html ]. Read it.
Ori Berger
Wednesday, February 4, 2004
This thread should definitely get "bold".
hooters
Wednesday, February 4, 2004
along with every other thread on religion and politics
magoo
Wednesday, February 4, 2004
> I'm sure that's not too wise if you were using C/C++. Detailed reasons left as exercise for the reader.
Care to elaborate? Some readers are not C/C++ programmers. I am curious, but don't really care enough to find out on my own.
NathanJ
Wednesday, February 4, 2004
The worst thing about Hungarian Notation is the whining you hear from other coders.
Hungarian notation was helpful when I was writing C code without an IDE. When I switched to Java without Hungarian notation, it took me about a day to get used to its absence.
Julian
Wednesday, February 4, 2004
Trading underscore for member variables is deprecated and considered harmful.
Jorel on Software
Thursday, February 5, 2004
This question comes up every couple of months on JoS.
What's bad about Hungarian is that hardly anyone understands what problem it was intended to solve, and therefore hardly anyone uses it effectively. It's actually not bad if you use it as Simonyi originally intended. Two short articles I wrote on the subject are here:
http://blogs.msdn.com/ericlippert/archive/2003/09/12/52989.aspx
http://blogs.msdn.com/ericlippert/archive/2003/09/16/53015.aspx
Eric Lippert
Thursday, February 5, 2004
Troll 77 has a really funny comment, but I guess only to people who now a bit about Fortran77.
:)
Roel Schroeven
Thursday, February 5, 2004
NathanJ:
Potential for name collision with compiler/library names:
Identifiers containing a double underscore or beginning with an underscore and an uppercase letter are supposed to be reserved for this.
In practice, it is not uncommon to find compilers/libraries which have some internal names beginning with single underscore and lowercase letter
So it's sort of asking for potential cross-compiler problems
S.Tanna
Thursday, February 5, 2004
"tbEmplID, btnLookupEmployee, lblEmplID"
I am surprised that nobody else called on this. Why use the entire word "Employee" on one variable, and an abbreviation "Empl" on another variable?
In addition, there is another flaw with the naming convention similar to this post:
"strCurrentFolder or szCurrentFolder"
When I read that, my mind translated it as “s something Current Folder and s something Current Folder."
As I read the rest of the post, I came to a realization that those two variables were actually different. I am surprised that nobody else called up on the fact that str and sz is far too similar at a 'glance' for someone who is not trained with the syntax.
Both of the flaws would cause a huge headache during development and debugging. It is more difficult to remember non-consistent rules (“Empl is good here, but you should use Employee there…”), and similar spelling (“lbl” and “tbl”) that is not obvious to untrained developers (In fact, with many different ‘standards’ in the industry, we all are untrained.)
It is the same problem with the original "EmplID" - "lbl" and "tbl" can be very tricky to read especially at 9pm at night during a long debugging run. "labelEmployeeID" and "tableEmployeeID" is far clearer. So are "CurrentFolderIndex" and "CurrentFolderSize.”
-T.J.
T.J.
Thursday, February 5, 2004
> strCurrentFolder or szCurrentFolder
I was not suggesting using both, just one or the other
Nobody seems to have commented on my real point, which was that people don't name variables (in my example, see above)
CurrentFolderIndex
CurrentFolderName
But tend to use "CurrentFolder" for both, and hence I find
nCurrentFolder
and
(say) strCurrentFolder
Preferable to have having to guess whether they mean the array index or the name of the current item.
S.Tanna
Thursday, February 5, 2004
Yeah, I really enjoyed Troll77's comment, too ...
Matt
Thursday, February 5, 2004
Ah, I understand. Referring to your point, I do prefers the long names. I DO use the long names. But then most of my co-workers do not.
They don't care.
T.J.
Thursday, February 5, 2004
 Recent Topics
Fog Creek Home
| 
