Should I use Hungarian notation when coding WinAPI apps? [closed]

Question

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?

Answer 1

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

Answer 2

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).