I started typing a comment on Pete Bell's post Why Not Hungarian, but it got a bit too long so I've put my two-penn'orth here.
Hungarian notation, for me, can be very useful, but maybe not in the form that's most commonly understood. I've heard the argument that the original intent behind Hungarian notation was to declare what KIND OF THING a variable is - but this got mistranslated into what TYPE a variable is, and the two are not the same -
For instance, in the last big CF project I did, I took to declaring strings that contained markup with a "htm" prefix, and strings that may have character codes - such as from textarea input - with a "raw" prefix. Similarly URL-encoded strings get an "enc" prefix. They're all strings, and traditional Hungarian notation might give them all the same prefix - but if you do it this way, as soon as you started typing a line like:
<cfset htmContentForDisplay = rawInput />
you immediately know that something is wrong. The variable prefixes themselves make you think "Hmm - that's not going to work.... I need to do some intermediate processing to convert the formats there"
In a strongly-typed, pre-compiled language like Java or C++, then Hungarian notation can just get in the way - you've got the compiler as a type-safety net, and anyone who's ever tried to do anything meaningful with MFC will certainly testify to the horrors of things like "lpszhwndmyWindowHandle". But I think that in loosely-typed languages such as CF, Hungarian notation has it's place if you use it properly - remember, "a Hungarian is the only man who can follow you into a revolving door and come out first" :-)
3 comments:
I think the way you use Hungarian notation is the way it was originally envisioned. Your usage explains the conceptual data, not the data types. I think what most people have a problem with is the use of HN to show actual data types: strText, arrArray, intNumber.
Personally, I like it, but that's just me. But I think your usage is the technically correct one.
It was inspired by this post :
http://www.joelonsoftware.com/articles/Wrong.html
I also think there's something to be said for the "strict data type" interpretation, as it can have a similar effect - e.g. lines like :
<cfset txtAString = ntxtAUnicodeString />
- should set off alarm bells just as well. And I think that's the point - the intent behind the usage is all important, of "making wrong code LOOK wrong"
Agreed - definitely a tool to have in your tool kit, but as you mentioned the benefits are for conceptual distinctions more than primitive type matching and I find it is something best applied sparingly :->
Of course, with a well structured OO app, you don't have that many variables just floating around so you should just be able to scroll up a few lines to the var statement or the cfargument scoping to see the data type.
Post a Comment