I bet that most of your for loops on integers use i as a
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
In general, I have to admit that I