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):String
Now, 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.