Hungarian notation

Do you use Hungarian notation?

  • Yes

    Votes: 12 33.3%
  • No

    Votes: 24 66.7%

  • Total voters
    36

Zalbag

Limp Gawd
Joined
Aug 24, 2002
Messages
330
I am curious, how many of you use hungarian notation when programming? Why do you use it (or why do you not use it)?
 
No. I firmly believe in naming variables in a useful fashion (save my counters like i and j), but I find that Hungarian becomes more of a hassle than it's worth. If you write functions, classes, etc, well enough, you shouldn't have all that many variables floating around at once, or at least not many with wildly varying purposes. Since that sort of information conveyance seems to be the purpose of Hungarian, I find it largely unnecessary.
 
perhaps you should add an option 'what the heck is this'
 
Hungarian Notation in the Wikipedia

I like my variables to convey a SENSE of what the program is doing, not lock it in. If you decide to change one aspect of how a program works, you have to change ALL references to that variable because you changed its type or function slightly. No thanks.
 
Hungarian notation is morally bankrupt.

A variable's type belongs in its declaration and definition, not in its name.


"Of dubious practical advantage even for type-unsafe calls in C, or in environments when nearly everything is a type-challenged int or void* handle," she shook her head sadly, "and of no relevance at all in a type-safe object-oriented language like C++. This, you must unlearn. Warts are not information; they are disinformation."

"In sum, the compiler already knows much more than you do about an object's type. Changing the variable's name to embed type information adds little value and is in fact brittle. And if there ever was reason to use some Hungarian notation in C-style languages, which is debatable, there certainly remains no value when using type-safe languages."

"That," the Guru acknowledged, "is what I just said. The problem is the same whether you uglify the variable's name or not, and by uglifying it you have merely added useless maintenance work because then you must additionally maintain the warty name. If you are not yet convinced, my child, I have one small question for you now: How would you apply Hungarian notation to templates?"


Side story: I once saw a guy name a std::string with the Hungarian prefix sz. My reaction: "IT WILL ALL BURN"

My variable names have lengths proportional to how hard their purposes are to remember. In general, I structure my code so that variables have short scopes and easy to remember purposes, so my variable names tend to be highly terse. Long variable names then stand out as indicators that they serve an unusual, difficult-to-remember function (e.g. byte_with_longest_null_code).

The closest I ever come to embedding type information in a variable's name is when the variable doesn't /need/ a name - for example, vectors named v, strings named s, regexen named r, etc.

I do use something I call Stephan notation - the practice of highly abbreviating type names themselves. I find vector<unsigned char> tedious to type, especially because I use it as much as cats play with yarn, and vector<unsigned char>::const_iterator is even worse. So I typedef them:

vuc_t (vector<unsigned char>)
vuc_ci_t (vector<unsigend char>::const_iterator)
dull_i_t (deque<unsigned long long>::iterator)

In reality, my typedefs are to guaranteed fixed width types - boost::uint32_t, not unsigned long - but you get the idea. But I'm certainly not going to start calling my variables dus_ci_foobar and the like.

(By the way, I took a little time during my Microsoft interview to rant against Hungarian notation. Boy, that was fun.)
 
I did at first, but it quickly got to the point where the Hungarian notation named variables were lying to me. It also made a lot of stuff harder to read, which is the opposite of what it's meant to do.
 
Our programming guidelines at work encourage us to use them....so no choice for me!
 
Nope. The variable names I pick will make it clear as to the purpose and type of the variable. For example, I have a citation.class.php, and each instance of that class is named $citation since, well, it's a citation! It makes no sense to call it citCitation since that is clearly redundant.

This practice carries over into my C and Perl programming, and was existant in my Java programming as well.
 
I can see where it would be redundant in your "citCitation" example, but what if you wanted to name a "citation" something different? e.g. citFoo, or citBar?

Surely using the hungarian notation would be useful on these occasions?
 
Zippeh said:
I can see where it would be redundant in your "citCitation" example, but what if you wanted to name a "citation" something different? e.g. citFoo, or citBar?

Surely using the hungarian notation would be useful on these occasions?

That's the thing. You don't name a variable "Foo". You give it a meaningfull name.

I don't use hungarian notation because your variables all end up looking like they're written in Hungarian, and not English. It makes code harder to read. Plus, with today's modern IDEs, you can get the type of a variable just by hovering over the darn thing. Even Microsoft has abandoned hungarian notation.
 
I use it when I write in VB, as it's *always* something for someone on a forum or someone who's emailed or messaged me with a request. I figure that since I never see the code again and they do and it's usually not even a few hundred lines of code, it doesn't hurt to use it and it probably maked their life a little easier.

When I'm writing in anything else, C++ or PHP, I'll just use a meaningful name.
 
I think I sometimes follow some parts of it, but never completely and never always.

If I can follow what I'm doing, that's good enough for me. I don't need the hassle of following a rigid set of guidelines that don't do anything for me. (Of course, I've built (and maintain and expand) a large, complex system as my job and I haven't documented it to the point that my coworkers would be able to take over responsibility for it without massive pain (I'm also the only one who has ever worked on it), so perhaps my opinion should be considered with that in mind.)
 
I tend to use it when I'm writing ASP or in another procedural language (eg VB etc). Especially with ASP, because you have all manner of includes an' shit with variants that could be from anywhere - with Hungarian notation, you at least get some idea of a variable's scope and its intended type.

However, when I'm in an OO environment, like Java, I tend to avoid it like the plague, because it's simply not necessary.
 
I rarely use it, if ever... and I'd have to agree with lomn75's reasoning. If you've got that many variables in use at once and would otherwise have trouble distinguishing them, shame on you. There's always a better way to do things.

Of course, there's no reason against using it if it helps you, but I guess what we're saying is that it shouldn't be necessary for you to understand your code.
 
In a language such as C++, C#, or Java, I strongly disagree with using Hungarian notation. For local variables it's pretty easy to tell what something is so long as your names are good, describing what you're doing instead of being generic junk, and your function is short. Global variables are easily covered, since one should never ever ever use them. For Java and C#, function names need not be mangled since the compiler will really yell at you if you use the result in a way that would lose information (int64 -> byte, for instance) or would otherwise be incompatible. C++ is good about this as well, although not as good.
 
Most of the work I've been doing has been with C# or VB.NET, and since they are strongly typed languages there really isn't that much of a reason to use those conventions. Plus, with VS.NET all you really have to do is hover over the variable and it'll tell you the type if you aren't sure or need to know.
 
I never understood the general hatred of Hungarian notation. Adding that one character that makes my life so much easier on a daily basis.

Hungarian notation should in no way replace giving your variables meaningful names. The trick is when you're dealing with a couple dozen other coders, what they think is a meaningful name isn't always to you.
 
Back
Top