Hungarian notation is a topic that will almost certainly start a bar fight at just about any nerd hangout. Its similar to the "
airplane on a treadmill"
discussion. I am referring to the fact that the argument almost always
comes down to a basic misunderstanding of the issue and solution.
For example, from
Wikipedia we get this little gem.
- Bjarne Stroustrup (against systems Hungarian for C++):
"No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding
an abbreviated version of a type in a variable name) a technique that
can be useful in untyped languages, but is completely unsuitable for a
language that supports generic programming and object-oriented
programming—both of which emphasize selection of operations based on
the type an arguments (known to the language or to the run-time
support). In this case, 'building the type of an object into names'
simply complicates and minimizes abstraction."[5]
I believe that Mr. Stroustrup is 100% correct. Why would you
define a string as strFullName? The compiler/IDE wont let you assign an
int to it, and the IDE will even tell you that its a string. Good point
Bjarne.
From the same Wikipedia article we have this quote:
- Joel Spolsky (for apps Hungarian):
"If you read Simonyi’s paper closely, what he was getting at was the
same kind of naming convention as I used in my example above where we
decided that us
meant “unsafe string” and s
meant “safe string.” They’re both of type string
. The compiler won’t help you if you assign one to the other and Intellisense won’t tell you bupkis.
But they are semantically different; they need to be interpreted
differently and treated differently and some kind of conversion
function will need to be called if you assign one to the other or you
will have a runtime bug. If you’re lucky. (...) There’s still a
tremendous amount of value to Apps Hungarian, in that it increases
collocation in code, which makes the code easier to read, write, debug,
and maintain, and, most importantly, it makes wrong code look wrong."[6]
Ahh, THATS the money shot. You see, "type" is not a compiler
type, its a "dude, get your head out of you ass" type. I agree with
Joel and have used this convention for quite some time. For example
when I create a function that expects a string to be base64 encoded I
use (for example) the following method signature:
public function encrypt( usersDataB64:String):StringNow, the IDE will tell me that the function "encrypt" takes a single string variable called "
usersDataB64".
The variable name gives me the hint that it should be base64 encoded.
Neither the compiler nor the IDE understand the symantecs of this
variable, but the developer will based on the variable name.
And
of course the same applies for the return value. The above method
signature indicates that the encrypt function will return a string. But
in my code, I will return a variable with the proper name, for example:
return (usersDataEnc);usersDataEnc is a string, and it should be clear that it is encrypted based on its name. And as Joel points out, if I ever see the variable
usersData I
will know that its in plain text (not encrypted) and I wont have to dig
around to find out if its encrypted or not. As well, if I ever see
usersData
where the data SHOULD be encrypted, I know immediatly that I have a
problem. Either I have plain text where I shold have encrypted text, or
a have a misnamed variable. Either way, the code smells.