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.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Hungarian Notation – Use What Works, Spit Out The BonesHungarian Notation – Use What Works, Spit Out The Bones I am about to embark on the “religious” topic of naming conventions.  I was reminded of this topic by the short post, “Hungarian Notation, what do I think”, by Richard Dingwall. […]
  • Copy And Paste And BugsCopy And Paste And Bugs We all do it.  I’m sure of it.  It’s too easy. I need code that looks almost like something else I wrote so I just copy and paste it over to the new code.  Done. But at […]
  • SQL WHILE – SQL For ProgrammersSQL WHILE – SQL For Programmers The IF statement we looked at on Tuesday was pretty tame compared to the WHILE construct.Actually, the main thing you need to keep in mind is that WHILE is all you have.  There is no […]
  • Debugging TypeScript Under DotNetNukeDebugging TypeScript Under DotNetNuke I’ve been playing with TypeScript for the last couple of weeks and I’ve fallen in love.  Now I can write JavaScript code without having to switch between thinking about the problem […]
  • I, J, and K Should DieI, J, and K Should Die One of the hardest things we do as programmers is naming things.  But the easiest thing to name is counter variables and most of us do it wrong several times a day.Of course, I’m […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

  • 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.