Joel on Software’s latest bewildering article advocates correct use of the – often misunderstood – Hungarian notation: “Making Wrong Code Look Wrong“.
Basically, calling a variable
unBorder because it’s an unsigned int is pointless. What’s useful is to call it
xwBorder because it’s an horinzontal “x” coordinate (versus a bytecount for example) that refers to the window “w” (versus the screen or the document for example). If this doesn’t feel a 100 times better to you, go read the article now! :)
I really agree with the fact that knowning the system type of a variable when you read it is pretty much useless most of the time – especially in the age of typeless scripting languages like PHP. Knowing the semantic type of the variable is much more interesting.
As I have written before in my coding standard guidelines, there’s a situation, though, where I still like to use system types in my variable names: when I deal with Objects. For example I might use variable names like
First, because if the Objects are properly named, then the variable names refering to them will make sense.
But there’s more: as you might have noticed, I used the object name “File” as a suffix, not as a Hungarian prefix. The reason is that if I have a method called
File::rename() that I want to refactor for some reason (like merge it with
File::move() ), I might need to check every place where it’s called. Actually, as I have learned from b2evolution development, these things happen all the time on larger projects…
Now, by suffixing vars with the object name, I can easily do a project wide search for
File->rename( and I’ll find all calls to the method, in various contexts such as
log_File->rename() … you get the idea…
If I have one variable misnamed as in
list->rename() for example, I would not find it… unless I decide to search on just
->rename(… but I wouldn’t want that! It would get me a lot of noise like:
Holy Graal, a light had lit in my spirit ! Thanks you my Lord…
Kochise, who just thought about reindenting all his legacy source code