Software Debugged

Hungarian Notation is a variable naming convention invented by Charles Simonyi. It comes in two flavours:

• Systems Hungarian Notation, in which a prefix is used to encode the underlying representation of the identifier, for example dRadius to indicate that the radius is represented as a double presision number (i.e. prefixed with a “d”)
• Apps Hungarian Notation, in which a prefix is used to indicate the purpose or nature of the identifier, for example strName – the prefix indicates the variable is a text string but does not indicate how the string is actually represented (e.g. in C++ it could be a zero terminated C-style string, or an std::string from the standard library)

The form Microsoft used to use in their example code for Windows was a mixture of the two forms.

Hungarian Notation has always been one of my pet hates among programming practices. When I’ve met people who think it’s a good idea – and there have been many of them over the years – it has always amused me that if you ask them why they like it, they will (without realising it) tell you exactly why it’s a bad idea! For instance, they’ll tell you it helps you to know what’s what in a long piece of code; of course, they are oblivious to the fact that it is long pieces of code that causes the problem, and that HN is not a solution, just sticking plaster that lets people think they don’t have a problem that needs solving. The real problem is that most programmers out there seem to think that long stretches of code – not disciplined by being broken up into appropriately named functions – are both normal and acceptable. The truth is that when functions are used to discipline the code, it is easy to see what’s what because declarations are never far away from where identifiers are used.

The above is the main reason I think HN is pure evil! That is, because its use is indicative of a bigger and more important problem that is likely to go unnoticed. That is, people are using HN to solve the wrong problem! Moving on though, here are other reasons not to use it:

• In the case of System HN the prefix exposes representation, which as the code evolves over time may well change. The prefix then ends up lying. Ironically, the HN prefixes – in long stretches of code – do not let programmers off looking at declarations anyway. One can never really rely on the HN prefix being correct
• The HN prefix is a wart of the code face! It presents an obstacle the brain must get past when parsing the identifier name. The drag factor introduced by such impediments to the understanding should not be underestimated!

Note that Microsoft haven’t been using or recommending the use of HN for quite some time now. Programmers out there, please, please let HN go the way of the dodo. Instead:

• Choose your identifier names carefully so the name implies purpose. This is far more beneficial to the understanding than any prefixing system
• Use the facilities provided by your programming language – functions, structures, and if you’re using an object oriented language, classes – to bring discipline to your code, such that understanding it follows naturally