What's Up With Hungarian Notation?

RE: What's Up With Hungarian Notation?

dave sanderman — Tue, 16 Sep 2003 05:18:00 GMT

another comment about 'I already know the type because of the declaration' is: often the declaration and use are distant from each other. the benefit of using hungarian in that case is that you don't have to look at a line of code and then grovel around to find out how the vars are declared.

RE: What's Up With Hungarian Notation?

Eric Lippert — Tue, 16 Sep 2003 05:35:00 GMT

Though you make a good point, I'd counter that by saying that (a) many developers now use some pretty sophisticated editors that can find the declaration very quickly, and (b) I try to keep my routines under three screens long. If its a local variable, the type is nearby. If it's a member variable or a global variable then sure, sometimes it is a pain to find the storage type, but really, how often do you care whether that counter is a UINT or a DWORD?

RE: What's Up With Hungarian Notation?

ZorbaTHut — Tue, 16 Sep 2003 06:29:00 GMT

I've always thought that it would be handy to make that sort of thing a compile-time error. Describe the set of prefixes you plan to use and how they can be associated with each other, then make the compiler scream at you if you do something Wrong.

RE: What's Up With Hungarian Notation?

Mike Dimmick — Tue, 16 Sep 2003 15:06:00 GMT

There's always the Ada way of doing things: creating new integer types, and new subtypes. However, I suspect that most of us don't have the patience for that. As far as I'm aware, there aren't any mainstream languages apart from Ada that allow us to declare the exact valid range of an integer variable, or differentiate apples from oranges within the type system (i.e. with support from the compiler). There's less need for Hungarian prefixes in a strong type system like Ada's, or the user-defined type systems of C++ - because the compiler can tell you you're making mistakes. However, if you have conversion operators and alternate constructors in C++, there's a chance of introducing type errors.

RE: What's Up With Hungarian Notation?

Ed Ball — Tue, 16 Sep 2003 20:54:00 GMT

My primary argument for Hungarian has to do with making code easier to read. Even if the declaration of a local/member/global variable is just a screen away, that's still too far if I'm trying to quickly figure out this line of code where the debugger dropped me. My philosophy for Hungarian notation actually falls between your "sensible" and "pointless" philosophies. I don't look to Hungarian to tell me whether an integer is 16- or 32-bit, signed or unsigned, but I also don't look to it to tell me much semantic information -- I figure the actual variable name is good for that. I do want Hungarian to tell me that the variable is an integer (versus a real number, or a Boolean, or a rectangle, or a pen, or whatever). So "nChildren" is probably the number of children, whereas "bChildren" is probably true if there are any children, and "astrChildren" is probably an array of their names. It communicates enough of the type to know what the basic operations on the variable are, and, combined with the variable name, gives solid semantic information.

RE: What's Up With Hungarian Notation?

Tim Scarfe — Sun, 21 Sep 2003 19:05:00 GMT

As no-one has commented on this yet, I will note that it there is no argument against using it in a language like JScript where there are variants involved. It makes the code 10 times easier to read and look pretty cool to boot :)

Reading Code Is Hard

Fabulous Adventures In Coding — Mon, 14 Jun 2004 21:52:00 GMT

re: What's Up With Hungarian Notation?

Dave Anderson — Thu, 17 Jun 2004 20:59:00 GMT

<< ...there is no argument against using it in a language like JScript where there are variants involved. It makes the code 10 times easier to read and look pretty cool to boot... >>

Ugh. JScript is the WORST kind of language in which to use Hungarian notation, as there is no way to enforce typing.

And I disagree with claims that Hungarian Notation makes code easier to read.

re: What's Up With Hungarian Notation?

Mike Fitzpatrick — Mon, 21 Jun 2004 06:23:00 GMT

I lovr hungarian for all the right reasons. I agree wiht the blooger's comments, but you've got to start somewhere...

http://CodeInsight.com/Docs/Programming Standards.doc

Hugarian notation - it's my turn now :)

Larry Osterman's WebLog — Tue, 22 Jun 2004 21:00:00 GMT

re: What's Up With Hungarian Notation?

Jeff Clark — Tue, 22 Jun 2004 19:10:00 GMT

If you do use hungarian it also seems like you need to setup some standards so everyone uses the SAME prefixes (however you plan on using then). If you have multiple people using different prefixes for the same thing then you still end up having to go look at the definition because you don't know what stupid thing is. Also we'd always run into problems with people manufacturing prefixes for classes they create so you end up with wpbmObject or something indecipherable like that.

I used to use it but we hit so many problems due to people making up their own rules that we don't use it anymore. At first I was pretty skeptical about not using it but as long as you take care and name things appropriately it's not really missed. Of course if people named things appropriately in the first place then using it would probably not have caused as many problems as it did.

Hugarian notation - it's my turn now :)

Larry Osterman's WebLog — Thu, 24 Jun 2004 08:06:00 GMT

re: Hungarian Notation

Cyrus' Blather — Thu, 10 Mar 2005 04:06:00 GMT

re: What's Up With Hungarian Notation?

Chris — Wed, 27 Dec 2006 21:55:27 GMT

Hungarian doesn't have any place in production code. It goes beyond "messy" or "dirty". Most variable names imply their data type. ID is int, Name is string, so on. For complex data types, you get into trouble when people start using their own abbreviations. Class People does it abbriviate to pplPerson? or plePerson, what if there's a pointer ppple? Also most IDEs nowadays(especially VS) provide abundant hover over which tells you data type, among other things.

Redundancy is bad.

re: What's Up With Hungarian Notation?

Bruno — Sat, 30 Dec 2006 11:09:48 GMT

Hungarian notation is only useful if you name your variables things like "blah" and "foo". If you give your variables good, descriptive names, this is a complete non-issue.

re: What's Up With Hungarian Notation?

Bruce Leggett — Fri, 05 Jan 2007 23:37:44 GMT

Hungarian Notation is psychologically inefficient and counter productive. First, you must learn all the prefixes (this could be a burdensome task in some cases)! Finally, after you "Hungarianize" your code now when you maintain it you have to decode and disect those "Hungarianized" variables. Both are an unecessary mental blow and loss in productivity. Use Descriptive names as Bruno stated. Period.

re: What's Up With Hungarian Notation?

Robert Brown — Sun, 14 Jan 2007 03:09:09 GMT

As an embedded systems programmer (C), I find Hungarian notation to be extremely beneficial. By "embedded" I mean true embedded programming where an oscilloscope is often used to debug software. Hungarian is a fabulously quick way to assess whether you're mixing fixed-point math with floating point math. Further, it allows a very quick way to determine if you're trying to do mixed integer math between longs and ints (for example), which can cause rollover problems. When implementing software filters that need to run fast (fixed-point) yet need to be reconciled with human-readable data (floating point), Hungarian is a really powerful way to ensure your math makes sense. One glance tells you if you're trying to right-shift a float (oops). Different descriptive variable names in the embedded world often become too cumbersome: iVoltage and fVoltage (Hungarian) is a lot more readable than VoltageFromADconverter and VoltageForUserInterface. Hungarian notation has helped me catch dangerous bugs before software deployment (for example, erasing on-chip flash memory 65535 times instead of just once when mixing longs and ints...given that flash devices can do somewhere around 10k- 100k write cycles before they die, you can see the value in catching this type of bug quickly!).

That being said, I can completely understand not using Hungarian for more abstracted languages like Java, C#, etc. The lines between atomic data types are blurred with these languages (which is good for these languages because it makes for easier, faster programming), so type-checking has less serious consequences.

I think it comes down to applying Hungarian where it makes sense. I never devise long cryptic Hungarian prefixes for complex data structures (for such cases, the name is descriptive enough). Hungarian really helps to prevent type-mixing during mixed math, and to specify scope for improved readability. In any given system, I often will use a platform with Hungarian (C in the embedded processor) and without Hungarian (C# in the PC-based user interface software).

Just use the right tool for the job if it helps.

Even good Hungarian notation is still bad

Greg Beech's Tech Blog — Mon, 23 Apr 2007 20:52:07 GMT

I was bored this weekend so I ended up trawling through a bunch of blog archives and came across posts

re: What's Up With Hungarian Notation?

Daniel Earwicker — Thu, 25 Sep 2008 18:42:53 GMT

To celebrate the 5th aniversary of this post...

If a variable stores the count of something, put 'count' in its name. That way, you get a more readable version of the semantic indicator and no one can accuse you of being Hungarian. Modern IDEs solve the problem of typing long names (auto completion) and also of looking up the representation (Find declaration...)

Databases: 50 years of stupidity « relationary

Databases: 50 years of stupidity « relationary — Sat, 31 Jan 2009 03:54:43 GMT

PingBack from http://relationary.wordpress.com/2009/01/31/databases-50-years-of-stupidity/