The case against i, j, and k


One of the greatest programming books of all time is Code Complete by Steve McConnell.  I often recommend this book to new programmers and when I was running the IT department of the Dot Com I was working for, I made it required reading.

In it, Steve makes a great case against using i, j, and k for incrementing variables as in, for(i =0, i < 20;i++) because it describes nothing about what the code is doing.

What I intend to do today is to demonstrate from a real-life example that he’s right.

Back in the day when I was programming C++, I was asked to find a bug in some code we had that wasn’t working for a specific dataset we had provided it.

I literally spent 4 hours trying to track it down.  You know how the routine goes.  Set break points at various locations, check values, etc.

I even resorted to stepping through the code one line at a time, which was tough because the loop iterated for thousands of times… actually it was 3 nested loops that each iterated for thousands of times.  Doesn’t exactly lend itself to stepping through the code a line at a time.

And then I finally saw the problem


That’s the condensed version.

The basic problem was that i was getting reset because when the person put in the inner for i loop, they had forgotten about the outer i loop.

Looking back, I bet this was a result of the copy and paste problem I discussed yesterday.

This particular problem could have been solved in one of two ways.  One is to not have so many nested loops in such a long function.  Given the length of the method this loop showed up in, each loop should have been in its own method.

But how much clearer could this code have been if they had used variables that describe what they are looping through?

If you are looping through an array of bananas, instead of using i,j, or k, you should use a bananaIndex variable.

The ONLY place that i, j, and k work for variable names are in demo code where you are trying to demonstrate a concept and the code has a very short life span OR possibly, when you only have one short loop where there is no chance of your loosing track.  I favor using descriptive iterators all the time.  Once they are in your code, the likelihood of them being changed is quite small.

Related Post

2 Responses to “The case against i, j, and k”

  • Mark:

    Alternately if you declare your i’s , j’s, k’s inside the for statement the compiler would catch the inner re-definition of i as an error. for (int i=0;i<someVar;i++) …

  • Dave:

    You can do a lot of things, that doesn’t make them right.

    First, you can’t use that feature in all languages.
    Second, even the languages where you are suppose to be able to use the feature have been know to be buggy in this regard.
    Third, your suggested method is a much harder standard to enforce than a naming convention.
    And finally, and most importantly. i, j, and k tell you nothing about what the code is suppose to do.