Advertisement

How many of you uses Hungarian notations?

Started by November 30, 2000 11:55 PM
81 comments, last by vbisme 24 years, 1 month ago
quote: Original post by Countach
For example, with 'dwIndex' what does the extra 'dw' prefix tell you?
Nothing, since an index is always an integer.


That's the very reason for using Hungarian Notation, thanks for proving my point . In your example, index is NOT an integer, it's a DWORD. Meaning it will ALWAYS be 4 bytes. For 32-bit operating systems an integer is also 4 bytes, but that's just a coincidence. Back in the 16-bit OS days, an integer was 2 bytes, and when we switch to 64-bit OS it will be 8 bytes. My point being tho, it is a waste of memory to always create your Index variable as an integer if it only needs to be a short. And you'll run into bugs if Index needs to be an unsigned int rather than a normal int. Hungarian Notation allows you keep track what type it really is.

quote: Original post by Anonymous Poster
Houdini:
"You'll need to know the type if you want to do a for loop from 0 to ButtonCount. No need to declare x as an integer if ButtonCount is a byte, because it's a waste of space. And if ButtonCount is a unsigned int then you need to make sure that x is also an unsigned int. Or, for instance, if you need to create a
temporary variable to hold information in that variable, you need to know the type. So yes, there are most definately times where you need to know the type of a number variable."

When writing hungarian notation you must remember the type of 'ButtonCount' when writing 'ButtonCount' otherwise you would not write the right prefix. Wouldn't it be better to just remember the type of 'ButtonCount' when declaring x than remember this all the way troughout the function?


Using Hungarian Notation with small projects will help you to remember the variable type because you are typing it's abbreviation constantly. Also, looking at the function above you to see the variable type is much faster than loading up the header file to check it. If no functions around it use it, no biggy, load up the header file. Remember, Hungarian Notation isn't primarily used to help WRITE code, but it help DEBUG code.

quote: Original post by Anonymous Poster
Houdini:
"As for not remembering variable names, it's not really an issue. Hungarian Notation is useful for writing code, but it's even more useful when fixing bugs or reading someone elses code. In those cases the variable is already there, and you don't have to remember it."

Agreed, if the coder has written the right prefix. But if I am debugging I should now the code good enough to know what type this variable is.


You must have never worked on a VERY large project, and/or never worked in company as a programmer. My company's program I'm working on, as of today, contains 484,000 lines of code. There are tens of thousands of variables in the program. Even if I wrote the whole program myself I wouldn't remember every single variable type.

Which brings me to my next point. I didn't write the program. The very first thing they had me do when I started working here is fix bugs, and I had never even seen the source code before. Although the program used SOME Hungarian Notation (m for member variables, which helped out TREMENDOUSLY) I constantly had to search to find variable declarations thoughout it's 2040 files. Not fun.

quote: Original post by Anonymous Poster
Houdini:
"Heck, what are you going to do if you need to print out a hard copy of some code? You can't use the editor to do the mouseover for the type. You'd have to make sure you printout the declarations of all your variables, even if all you really needed to printout is the one function you are having problems with."

If I would print out a hardcopy I surely would not care wether the variable is a short or an int. The only variables I would have to do a mouseover on are the ones which are members of a class or globals. I mean the function shouldn't be so big it won't fit on max 2 pages. If I was debugging using the hardcopy I would get to know a little more about the function so that I at least know what type the variables are.


Of course you'd have to search before hand to find out if a variable is a local, global, or member variable. I've had a few times where an algorithm just wasn't working correctly so I printed off the function and had someone else look at it. With Hungarian Notation they know the variable type and don't have to look at multiple other printouts just to make sure the variable types match up.

quote: Original post by Anonymous Poster
Houdini:
"People who use C++ normally wouldn't have this problem. For instance all of my variables are kept private in classes with a Get and Set function for each variable that may need to be changed outside the class.

So how do you know the type, then?


You look at the function/documentation. Remember that Hungarian Notations primary use is for debugging, not for developement. If I create a library I don't want to force other people to use Hungarian Notation by using it in the function names as well. And properly written code should have no global variables so that won't be a problem. People who use that library would use it just like any other code, and it won't break their own naming convention.

quote: Original post by Anonymous Poster
Houdini:
"Hungarian Notation is basically a form of commenting. It makes programming a little easier, but mostly it makes bug fixing and understanding someone else's code much easier. Just like comments."

Overcommenting is extremely irritating.


Yes, but many people don't consider that overcommenting. In very large programs with many people coming in/out of the company, Hungarian Notation is an unbelievable asset.


- Houdini

Edited by - Houdini on December 4, 2000 11:46:10 AM
- Houdini
quote: Original post by Houdini
Original post by Countach
For example, with ''dwIndex'' what does the extra ''dw'' prefix tell you?
Nothing, since an index is always an integer.


That''s the very reason for using Hungarian Notation, thanks for proving my point .


No one ever reads Simonyi''s original thesis.

The tags attached to variable names should indicate the ABSTRACT type, not the CONCRETE type.

What is an abstract type? In this case, an index variable should be named idxRandom or some name like that. Or simply i for index.

Never attach the concrete type to a variable name. It leads to more hassles than necessary.

Also, you can use non-integer types as lookups into non-conventional arrays. I.e. maps of strings to objects. Using idx as a type prefix preserves the semantics of the intent while allowing you to change the implementation w/o screwing up any logic in naming.

Also, names should be directly proportional to the scope they''re in. If you have an index variable for a single for loop, naming it ''i'' is fine. If you have a global index value, you better damn well give it a descriptive name so programmers know what it is. Comments certainly help also.

MSN
Advertisement
Long time since I''ve been here the last time and the first thing I hit is a discussion about the Hungarion Notation. Very interesting to read the thoughts of several people, some people do use it and some people don''t and have their own standards...and some even use a mix. I guess the latter is the one I use, and mainly due to my work as a programmer and using several programming languages. The hungarian notation is very usefull when it comes down to just C/C++ and I used to follow the hungrarian notation due to Charles Petzold''s famous books... But using additional languages like Visual Basic, J++, PHP, ASP and a whole bunch of more languages we defined our own standard at work as to make it readable for ourselves. It''ll cost you some additional time at first but after a while you''ll write it all down like it is nothing.

Regards,
CJ
I HATE HATE HATE reading code that doesn''t use something like Hungarian Notation. it''s just damn unreadable and looks horrible. It''s like uncommented C code. Look at any Windows programming book, they use this notation because it is simply a requirement for readable code just like comments or classes.

The argument that the compiler tells you the type of the variable is just plain stupid. Do you want to hover your mouse cursor over a variable and wait seconds for the tooltip to appear ??? I can look at my code and have the information in 1/24 second... It''s like coloring the code. It doesn''t provide any informations you can''t get otherwise, but just looking at it an recognizing the color is simply faster !

And all those "Index is always int" arguments are just plain stupid. "Buffer" can be a string or an unsigned char array. maybe it''s a global variable or a pointer ? YOu always have to look up in the declaration, this might take up to 10 seconds if you have to search trough big horrible written functions. Oh, and because the author of the code was to lazy to prefix it with m_ you might even have to look up at the class declaration...
I have this info in under 1 second, so HU let''s me work 1000% more effective.

There is simply NO argument that can beat this: Hungarian Notation makes code faster to read. It''s just a fact.
Tim--------------------------glvelocity.gamedev.netwww.gamedev.net/hosted/glvelocity
Oh, and to respond to that "ddpfPixelFormat" thing:

You say this is horrible ? What would "PixelFormat" tell you ??? Function pointer ? Array ? enum ? pointer ? int ? struct ? This would make the whole Win32 API and the whole DX API a big mess...

Win32 code with HU is perfectly readable, and it''s only so because of HU
Tim--------------------------glvelocity.gamedev.netwww.gamedev.net/hosted/glvelocity
quote: Original post by tcs
Win32 code with HU is perfectly readable, and it''s only so because of HU

Really now? Tell me, how wide do you think a WPARAM is? The W would suggest a word, would it not? WPARAM is a dword, not a word. Under Win16, it was a word, but became 32bit with win32. This is the problem with hungarian notation. When you change the type of a variable, you must either change the name of the variable, and do a search and replace for all the references to it, or keep it an anachronism so that you don''t hose a lot of code.

The type of a varaible is really not a useful thing to carry around in it''s name. I have never seen, nor can I even think of a situation where you would need to know the type of a variable and couldn''t readily figure it out based on context.

Advertisement
Notations are worthless unless the person reading the code understands what the notations mean. A person who becomes too accustom to a certain coding style will dislike any other conflicting style. There is almost no circumstance where I need to know the basic type of a variable if its numerical. And when i need to know the type, its not too hard to find out. Notations are not a c standard, so i do not.
cmaker- I do not make clones.
I kinda use hungarian notation in VB, yes. It''s a personal preference and to me, it makes stuff more readable.

Just one question: whoever came up with the zany idea of calling it hungarian notation?

- JQ
"Um, hi. Aaaaaaarrrgggghhhh" -me
~phil
quote: Original post by FordPrefect

Really now? Tell me, how wide do you think a WPARAM is? The W would suggest a word, would it not? WPARAM is a dword, not a word. Under Win16, it was a word, but became 32bit with win32. This is the problem with hungarian notation. When you change the type of a variable, you must either change the name of the variable, and do a search and replace for all the references to it, or keep it an anachronism so that you don''t hose a lot of code.

The type of a varaible is really not a useful thing to carry around in it''s name. I have never seen, nor can I even think of a situation where you would need to know the type of a variable and couldn''t readily figure it out based on context.



Uh, WPARAM is a variable type, not a variable name. How can you put the variable type in the name of a variable type? In other words, no, this is not the problem with Hungarian Notation.

As for you changing say, a variable from an unsigned int to a long, then yes, you''d have to rename the variable. Of course, this should only happen if you didn''t properly plan before coding (your own fault).

But heck, using that logic one could say, "Why make variable names descriptive? I mean, if you change the variable to do something a little different than originally intented then you have to change your variable name all over, so you should keep the variable name as generic as possible." Obviously this is just plain stupid.


- Houdini

- Houdini
quote: Original post by Houdini

Uh, WPARAM is a variable type, not a variable name. How can you put the variable type in the name of a variable type? In other words, no, this is not the problem with Hungarian Notation.

True, but the idea is the same. WPARAM is word paramater, LPARAM is long paramater. It has the same problem as hungarian notation.

quote:
As for you changing say, a variable from an unsigned int to a long, then yes, you'd have to rename the variable. Of course, this should only happen if you didn't properly plan before coding (your own fault).

Hardly. No matter how well you plan out your program, things like this are going to happen. If you can plan out your code to such minute detail and have the final working program ahdere to it strictly, then you are a much better programmer than I.

quote:
But heck, using that logic one could say, "Why make variable names descriptive? I mean, if you change the variable to do something a little different than originally intented then you have to change your variable name all over, so you should keep the variable name as generic as possible." Obviously this is just plain stupid.

Obviously it is, and this is not what I'm suggesting. The name of a variable should reflect what the variable represents, not how it is represented, as that detail can be tentative.

Edited by - FordPrefect on December 4, 2000 3:14:41 PM

This topic is closed to new replies.

Advertisement