I've recently started learning Win32 API and I hate Hungarian notation (those stupid prefixes in variable names which make the code looking ugly and almost unreadable), however as you may know it is absolutely everywhere in there! And this fact causes everyone to use it in their code too to keep kind of consistency... I suppose it is stupid question but anyway, should I do so as well? Will my code look strange or wrong if I don't?
Also: Not ever!
Nathon
2010-07-20 19:26:12
Wow, those are excellent reasons. I can't argue with that logic.
Steven Sudit
2010-07-20 19:28:54
Now tell us how you *really* feel.
Mark Ransom
2010-07-20 20:16:40
+6
A:
It seems that it's only because it's internal Microsoft coding standard. I personally use it only in the original (intented) way, and sometimes it makes sense (eg, I preffer int size_kb instead of defining type for size in kilobytes).
also check this article: http://www.joelonsoftware.com/articles/Wrong.html
ruslik
2010-07-20 19:26:59
I agree with this. Either use it for its intended purpose or don't use it.
Jonathan Sternberg
2010-07-20 19:31:26
I personally prefer not to put the type into the name of the variable (with exception for pointers), since the data type may change over time or the data type is not relevant in reading of the code. In the end, the compiler doesn't care.
Thomas Matthews
2010-07-20 20:32:55
@Thomas: That's entirely compatible with Apps Hungarian, although it conflicts with Systems Hungarian.
Steven Sudit
2010-07-20 21:21:34
+1 Very interesting article. I was not aware of the origins and distinction betweeen Systems and Apps hungarian.
David Relihan
2010-07-20 22:07:31
+3
A:
No -- the time for HN is long past. In fact, it's a good example of a second-system type of artifact that was really obsolete before it was even invented. A long time ago, the idea kind of made sense. When most compilers did little or no type checking, a somewhat systematic method of checking types by hand was an idea that at least had enough merit to be worth considering.
That's simply not the case any more though (and hasn't been for decades now). Even C compilers actually do real type checking nowadays, and compilers for nearly all other languages do considerably more still. Even a compiler that was obsolete and mediocre a decade ago will do this job far more effectively than encoding type information into a variable name gives you a hope of doing on your own. For that matter, even assemblers now do sufficient type checking to prevent many-to-most of the kinds of problems HN was intended to help with.
Worse, people who use HN frequently seem to assume it will do something useful, and because of that they ignore what the compiler could do. As a result, they actually end up with code that's considerably worse (fragile, borderline buggy) than if they hadn't used it at all. Huge amounts of Microsoft code display this sort of problem (e.g., DWORD getting used for all sorts of incompatible purposes, and people figuring that assigning one to another makes sense because they both have "dw" prefixes).
Worse still, code that uses HN is much less maintainable than code without it. As a prime example, look around at how much current code still uses an "lpsz" prefix, even though the concept of "long" versus "short" pointers was last relevant in Windows 3.1, close to 20 years ago now. In theory, this should all have been fixed during the migration to 32-bit code ~15 years ago -- but that would require huge amounts of work editing code for essentially no benefit (since the HN is worthless anyway, having a "correct" psz wouldn't really be any better than the "incorrect" lpsz).
Jerry Coffin
2010-07-20 20:02:11
This is a damning argument against Systems Hungarian. I'm not sure that it says anything about Apps Hungarian.
Steven Sudit
2010-07-20 20:08:02
It is useful when you have a variable, handle and ddx_link all associated with the same widget to have m_blah, c_blah and h_blah. Of course this tells you more about the joys of windows/MFC design!
Martin Beckett
2010-07-20 20:08:11
@Steven: HN is one specific notation. Other prefixes simply aren't HN at all. @Martin: prefixes like "m_" for class members simply aren't HN at all. I don't think they're very useful either, but their utility (or lack thereof) is orthogonal to the utility of HN (if any).
Jerry Coffin
2010-07-20 20:15:21
@Jerry: With all due respect, there are two branches of HN, and the one that's closest to Simonyi's original is Apps. See http://blogs.msdn.com/b/larryosterman/archive/2004/06/22/162629.aspx
Steven Sudit
2010-07-20 21:20:32
I would have completely agreed with all this if you had pitched it when I first learned of Hungarian. But I quickly grew to see it as a very consistent easy-to-use and easy-to-read naming scheme. When properly used, it's not about creating a second type system. I miss it dearly now that I'm in a non-Hungarian shop and I struggle to read these loooong variable names that don't express what the data is nearly as precisely.
Adrian McCarthy
2010-07-20 21:27:07
@Adrian: When I code C++, which isn't nearly as often as I like, I still do use (Apps) Hungarian. For C#, though, the benefits don't outweigh the costs.
Steven Sudit
2010-07-20 21:29:55
@Steven: I wasn't disagreeing with you. I was disagreeing with Jerry. The question is about C, not C++ or C#.
Adrian McCarthy
2010-07-20 21:38:19
@Steve: IMO, Hungarian Notation is exactly what Charles Simonyi defined it to be. See: http://cpp.snippets.org/code/hungnote.txt. With all due respect, I think hijacking the name to refer to something else is a lousy idea (just about as bad an idea as HN itself).
Jerry Coffin
2010-07-20 21:53:12
@Jerry: You'll have to explain what you mean by hijacking. Are you saying that Systems Hungarian doesn't qualify as Hungarian?
Steven Sudit
2010-07-21 13:33:15
@Adrian: I wasn't disagreeing with you, either. I guess that means we'll just have to agree to agree.
Steven Sudit
2010-07-21 13:35:43
@Steven: Well, *perhaps* I should explain further, but I've already devoted a lot more time to this than I think it's worth...
Jerry Coffin
2010-07-21 13:55:38
@Jerry: Well, that's entirely up to you. You are in no way obligated to endlessly answer my follow-up questions.
Steven Sudit
2010-07-21 15:13:58
+1
A:
If you're working on a larger team that has adopted a coding convention (HN or not), then follow it, even if you hate it (with one exception described below). If you're just coding for yourself, or you're on a team that has a more laissez faire attitude towards style, then go with what makes life easier for you.
The problem with coding conventions (especially something as artificial as HN) is that everybody has to follow them; if only half the team bothers to use HN properly, then nobody gets any benefit out of it at all, and you've just made your code harder to read for nothing.
Having said that, do not follow the idiotic convention of prefixing integer variables with i or strings with lpst; the sooner that bit of silliness dies off, the better. HN was intended to convey more abstract semantics; the goal was to identify which objects were safe or appropriate to use for a particular operation (the Joel on Software article linked to by ruslik makes a pretty good case for it). IOW, variable names should denote usage, not type, and HN was an attempt to codify usage.
Personally, I prefer using meaningful English (or native language of your choice) names that tell you explicitly what you're dealing with, rather than some artificial coding scheme; going from Joel's example linked above, I'd just use names like rawName and encodedName as opposed to usName and sName. It conveys much the same semantic information, and it reads better as well (IMO, anyway).
John Bode
2010-07-20 21:40:17
+1
A:
Joel on Software has a fantastic article explaining why (a) you SHOULD hate the Hungarian you see in windows Apps, and (b) why you should seriously consider using it.
If you are developing in C, the flavor of notation called Apps Hungarian is indispensable and will help you write correct code. If you are developing in a type safe OO language like C++, you should NOT use Hungarian as its just not needed.
Chris Becke
2010-07-21 08:16:18
Arguably, it is still of value for the C-ish parts of C++. I'm thinking specifically of being able to distinguish between ach, psz and so on.
Steven Sudit
2010-07-21 13:34:37