Hungarian Notation

is bollocks.

Why the fuck are they still teaching that shit? Ironically enough, they usually teach it as the Patron Saint of Maintainable Code.

Most people don't understand Hungarian notation. I don't use it myself, but when someone brings it up, I can pretty safely assume that they've only heard of the perverted form used by the MS OS division.

>>2
The fundamental precept of Hungarian Notation that I've been taught is flawed; it completely thrashes everything behind encapsulation.

the original idea hungarian notation as explained by joel of joel on software is ok. still, I'd rather have a better type system or make some kind of runtime error come up rather than putting up clues to warn myself about bugs on my code.

>>3
Do you mean the version that prepends a datatype-specific identifier to variable names?

>>4
Yeah, that was a hack trying to patch up the sucky type systems of C and C++. It's not a very elegant thing to do, but in those languages, the choices are pretty limited.

>>5
Yep.

Methinks I've been taught the bastardized, MS-bullshit version?

>>7
Well, the original version was invented by a MS employee too, it was another division of MS that bastardized it.

>>8
Apps Hungarian Notation looks like a good idea.

Hungarian notation is RETARDED. Thread over.

>>10
which one?

>>10
Guess which category of >>2 you fall into!

szCStringVariable;
dwUnsignedLong;
pObjectPointer;
nCountVariable;
etc...

Can somebody what the big difference between the MS-Version and the original version is that makes one a total failure and the other not?

>>14
Can somebody else Google it?

>>14
Do: >>15

>>14
IIRC, the wikipedia article spells it out.  Fuck you if I'm going to bother with a link.

PerformActionManyTimes(lpszFuckMe, lpsattrSecurityAttributes, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL)

(BTW, NULL should have been nullNULL.)

Hungarian notation, even if used properly, is retarded. If the kind of data a variable is bound to is not evident, you're doing it wrong. And I say kind because you shouldn't need to know or care about the type - except if you have a shitty type system like Cfags do.

Oh, and I forgot. It looks like shit. Like haskellFaggotShit.

>>19
humpBackCase is only used in Haskell because the underscore has a special meaning in LaTeX math-mode and therefore mathematically inclined people will associate it with subscript notation. Which, IMO, is completely appropriate given that Haskell permits prime notation too.

>>12
Please. There's no right way to use hungarian notation. At the very least you're mixing documentation with nomenclature, a horrible idea at the best of times.

The main benefit gained is that in codebases approaching spaghetti QUALITY, one can in theory (and that's assuming that the names have been maintained!) grab the type of a variable from its name alone. And that's a very bad absolutely no good at all thing in the first place (ignoring good naming practices): where it matters, a variable's type can be understood from context! One doesn't apply numeric multiplication to strings, or pointers, after all.

Also, when you have a codebase approaching that kind of QUALITY, you might as well go home and string yourself up. Hungarian notation is only going to make an already horrible maintenance nightmare worse. And maintenance is where most software development occurs these days: there is no code that doesn't need to be maintained except that which performs no useful function.

>>20
Insane syntax GET

Also, why not DecentCamelCase?

>>22
CamelCase is reserved for DataConstructors. I guess that's ML heritage showing. Also it looks brutish when used for every damned function reference etc, like C#.

(In contrast humpBackCase is like... "well I'm meek and tiny UNTIL YOU GET TO MY SECOND WORD HA HA HA HA HA")