Web/database development and more...
« Testing web applicationsQuel avenir pour Dreamweaver? »

Hungarian notation on steroids: semantic types & suffixes

11.05.05

Hungarian notation on steroids: semantic types & suffixes

  23:51:00, by fplanque   , Categories: Développement
Hungarian notation

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 source_File and destination_File!

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 source_File>rename(), destination_File->rename(), temp_File->rename(), 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: some_Collection->rename(), some_User->rename(), some_Group->rename(), etc…

1 comment

Comment from: Kochise [Visitor]
Kochise

Holy Graal, a light had lit in my spirit ! Thanks you my Lord…

Kochise, who just thought about reindenting all his legacy source code

2005-05-12 @ 21:06