I'm told there's been some debate about Hungarian Notation recently (as in within the last 24 hours). I won't go into too much detail about the history of Hungarian Notation, or even what it is, because these are being disputed. The short version is that some Hungarian guy who worked for Microsoft invented a notation, and since his name was hard to pronounce, instead of naming it Simonyian Notation, they named it Hungarian Notation. And then apparently, people misunderstood what Hungarian Notation was, and they felt it was a bad idea, but if you actually look at the paper Simonyi wrote on the topic, you can supposedly see that it's a good idea. Discussion includes Making Wrong Code Look Wrong and We Are All Hungarian Notation Users. Yes, Even You! (the latter probably assumes you've written at least 1 computer program).

So the idea behind Hungarian Notation is basically to put a prefix in front of a variable name for informational purposes. It's a bit more specific than that, but if I try to be more specific, I open myself up to attacks about misinterpreting what Hungarian Notation is. For example, if I write "Hungarian Notiation is putting a prefix which indicates the type of a variable, for example the prefix i to mean Interger, or us to mean Unsafe String" then people might jump on me and say "It's not a prefix which indicates the type! It's a prefix which indicates the kind!" or vice versa.

Anyway, it looks like the main purpose of using Hungarian Notation is to avoid putting a variable in the wrong location. The example that Joel uses in Making Wrong Code Look Wrong is related to unsafe strings in dynamic pages (you can read his post to find out what these "unsafe strings" are). The issue is that the language he's programming in (PHP?) has a type "String", and you could assign safe strings or unsafe strings to a variable declared of type String. If you ever print out an unsafe string to a website, you open yourself open to hacking. If you ever store a [strong]safe[/strong] (not, not [strong]un[/strong]safe, but safe) string in a database, you open yourself to data corruption. So you need both concepts, but you need a clear way to distinguish between these two. So here comes Hungarian Notation to the rescue, or so claims Joel. Just use the prefix us for unsafe string, and ss for safe string! So your variable name might be "ssUsername" and "usUsername" to represent the safe and unsafe version of a user's name respectively.

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.

If you follow Joel's recommendation, then you don't understand (or have misunderstood) the object oriented paradigm. He specifically acknowledges that "they are semantically different' they need to be interpreted differently and treated differently". When I read this, I (who modestly claims to fully understand the object oriented paradigm), immediately think "two different classes!"

Right now he's only working with one class called "String" and he's mixing unsafe strings and safe strings in there. Instead, he should have created two different classes, one called "UnsafeString" and one called "SafeString" (perhaps they both inherit from String), and make these two types be type-incompatible.

With Joel's technique, the code will "look" wrong.

Making wrong code look wrong is nice, but it's not necessarily the best possible solution to every security problem. It doesn't catch every possible bug or mistake, because you might not look at every line of code. But it's sure a heck of a lot better than nothing, and I'd much rather have a coding convention where wrong code, at least, looked wrong. You instantly gain the incremental benefit that every time a programmer's eyes pass over a line of code, that particular bug is checked for and prevented.

If you use my solution, the "Object Oriented" solution, the code won't only look wrong, it'll be wrong. If you accidentally assign an UnsafeString to a variable declared to be of type SafeString (or vice versa), the compiler will tell you "your code has an error in it". No need for a programmer's eyes to pass over a line of code. The computer checks for it automatically, and will refuse to produce a working program from that code. In effect, you CANNOT commit this mistake if you take the object oriented methodology. Contrast that with Joel, where you can more easily notice a mistake, if you happen to be actually looking at the source code for mistakes.

On Cedric's post "We Are All Hungarian Notation Users. Yes, Even You!", Cedric basically argues that you probably give your variables informative names, and that Hungarian Notation is essentially giving your variables informative names, therefore you are a Hungarian Notation User. Here's the comment I posted on his blog.

To me, the whole argument on hungarian notation is like the following short story:

A: Your code is awful!

B: What?! How dare you!

A: No, I meant that as a compliment! You see, awful means "causes awe", and I think your code is so great as to cause awe in me. Therefore, I say it's awful. People have misunderstood the word awful for years.

Some of the posts I read on hungarian notation can be simplified to "Hungarian notation is the act of giving your variables good names. Who is against giving your variables good names? No one? See, you are all hungarian notation users!"

Why bother labelling people this way? If you want people to use a certain naming scheme for variables, just tell them to use that naming scheme. If people don't like being called hungarian notation users because of some emotional responce to the term "hungarian notation", don't call them hungarian notation users. As long as we use a good naming scheme, who cares what that naming scheme is called?

I'm not saying I have anything against Hungarian Notation. As Joel says, it's better than nothing. In the particular example that he cited, I think a better solution would have been to use the Object Oriented approach. But there are other situations (though none come to my mind right now) where the OO approach wouldn't have added much. And there's no reason why you couldn't use both the OO approach (i.e. defining two new classes of Strings), and Hungarian Notation (give the variable name prefixes) at the same time.