Otaku, Cedric's weblog

We are all Hungarian Notation users. Yes, even you!

I bet that most of your for loops on integers use i as a variable.

And that nested loops use j and k.

When you iterate over a collection, you probably use it, and if you have nested iterator loops, you might consider renaming your iterators to make the intent clearer (itPerson, itAccount).

If you are writing GUI code, you have probably noticed that you need to decline the same word several times to mean "the widget", "the label of the widget", "the callback for this widget", etc...  And you probably came up with your own personal convention to keep your code readable.

Maybe without realizing it, you are using Hungarian Notation. Well, at least, the original Hungarian Notation, the way it was supposed to be used.  Not the newer one that imposed mangling the type of variables into their names.

In a very thoughtful entry, Joel Spolsky explains in details what the original Hungarian Notation was about, and why you should care.

Joel gets it.

He doesn't get everything, though (see below), but he understands the importance of conventions and how appearance of code is more important than it looks.  No pun intended.

A long time ago in a physics class,  a teacher gave me a tip that I never forgot and that I kept using for years on.

It was about making a sanity check on a result.  Physics problems usually require you to manipulate not only a lot of variables, but also a lot of very different concepts.  The solution to a problem is usually a combination of several "dimensions", such as "meter per square second" or "electron volt per square inches".  My teacher suggested that I should always calculate the dimensions of the results on both sides of the equal signs, and that they had to match.  If they didn't, then I was sure I made a mistake somewhere.  If they did match, then...  well, the solution might be correct.

If you did some basic arithmetic in school, you might remember a similar sanity check called "preuve par neuf" in French (interestingly, I have no idea how it translates into English and I'll welcome anyone who can tell me).  The idea was simply to verify that both sides of the equal signs have the same nine modulo.  Why nine?  Because you can calculate it by adding the digits of the numbers involved.  If the sums don't match, you are sure you made a mistake.  If they do...  your solution might be correct.

Similarly, network layers have been using parity checks to quickly verify if a packet was corrupted during a transfer.  There are various ways to do this, but they boil down to a similar idea:  use an inexpensive algorithm to make a quick sanity check on a result.

The original Hungarian Notation aimed to provide a similar hint to programmers:  point out obvious mistakes.

Code that equates a loop index to the height of a window is spelled out in the open for you to see.  No compilers or IDE will catch these errors, but a human might if you used some some convention consistently (come to think of it, it should be possible to teach an IDE what kind of Hungarian Notation you are using so they would flag the errors that Joel describes in his entry...  intriguing idea...  will have to think more about that).

Read Joel's essay on this notation, it will enlighten you.  At least the part on Hungarian notation.

Joel's later points on operator overloading and the evilness of exceptions are definitely more questionable.  And he is so well aware of it that his article include a rebuttal to his own claims.  Now that's intellectual honesty if I've ever seen it.

But still, his points don't make much sense to me and he actually contradicts himself in a few places, such as:

What all these rules have in common is that they are trying to get the relevant information about what a line of code really does physically as close together as possible

Joel fails to see that exceptions actually work toward that goal:  they keep the pieces of code that do the same thing close to each other.  They concentrate the business logic in one place and the error-treating logic somewhere else (which is usually where you want it).

To vilify operator overloading and exceptions, Joel uses the old age argument:

In general, I have to admit that I’m a little bit scared of language features that hide things.

While I sympathize with the feeling, it's clearly not the way we are headed, and the added complexity is simply thrown in because the problems we are solving these days have gotten more complex as well.

C was quite a jump in complexity for assembly programmers, but we digested it because it was necessary.  Between Joel's view of the world where languages should stick to the straightforwardness of C and Guy Steele's view that languages should be "growable", to the point that not only operators should be overloadable but the syntax of these languages and their semantics should be extensible as well, I side firmly on Steele's side.

And if you want to remain relevant in the next decade of software development, you should probably do the same.

 

Posted by cedric at May 11, 2005 10:12 AM