For 50 years i, j and sometimes k have meant basically "loop index".
It's easy to spell and easy to understand. Using long names for index
variables is common among inexperienced programmers.

Often the loop and index variable(s) are used to traverse an array or
other structure, and the long expressions that result from wordy index
variables are *not* necessarily easier to read, especially when you
are iterating over a 2D (or more) structure.

Something like "cell[i][j]" is clear to any reader who understands
arrays. In some cases short meaningful names like "row" or "col" are
ok.

/gordon

--

   There are lots of standards on this topic. The tricky part is choosing
which standard you and your co-worker and going to adopt.

   FWIW, I will use "i" (or "j", or "k", etc.) as my for-loop counter
variable.

   - Oliver

Jason Cavett wrote On 04/05/07 11:47,:

   There are two kinds of consumers of source code: compilers
and people.  Compilers have a good memory for detail, and don't
care what names you use: If all the variables were named l
and l1 and ll and l1l and ll1 they'd be perfectly content.  So
the selection of variable names should be motivated solely by
the rather different cognitive needs of flesh-and-blood readers.

   When I myself read code, it seems easier to read short names
than long ones.  On the other hand, short names can be cryptic;
my reading is not aided if I need to keep interrupting it to go
look for a comment on a variable declaration a hundred lines
distant.  I've found that a pretty reasonable balance is struck
if I let the length of a variable name depend on the "size" of
its scope.  I'll use short names for variables that are declared,
used, and abandoned in a "small" region of code, and longer names
for variables with more "staying power" whose visibility and
significance extend over wider spans.

   (Corollary: method and field names have significance
throughout an entire class and sometimes even beyond it,
hence their names should always be descriptive.)

   So, what category fits loop indices?  Well, it depends on
the loop -- that is, on how "big" the `// do stuff' is.  For
half a dozen lines `i' is fine; for half a hundred you'd want
`fragmentIndex'; for half a thousand consider refactoring.

   It works for me.  YMMV.

Like the others, I see nothing wrong with using i for a loop index, and good
reasons to prefer that common idiom in many cases (the fact that it /is/ a
common idiom not least amongst them).

It might be worth saying a bit about /why/ it is acceptable, although it
appears to break the general rule about preferring communicative names.

Somewhat less than half the point is that there is no real need for long
identifiers here -- that's to say that a (very) short identifier is just as
communicative as a long one in this context.  And -- all things being equal --
short identifiers are to be preferred over long ones.  (The qualification, "all
things being equal" is, of course, /vital/)   In any sensible code, the array
index's scope is limited to the loop over the array -- which is a very limited
scope, so the amount of information the identifier must convey is similarly
limited.  There is nothing for it to say that is not immediately evident from
the context in which it appears, simply because it only /exists/ in that
immediate context.

The bigger part of the point is that there (usually) is nothing much for the
identifier to communicate /anyway/.  It is an array index, and once you've said
that, there isn't (usually) anything else to add.  The meaning (usually) lies
in the thing found in the array, at the index, not in the index itself.

The repeated "(usually)" in the above are because of occasional exceptions to
the rule.  Perhaps the most common (which Gordon has already touched on) is
when you are considering row/column indexes in 2D arrays.  In such cases it can
be sensible to keep it clear whether an index varies over rows or columns.
That is especially true if you are also messing with X/Y coordinates in the
same code (such as painting a grid), since the normal English word order for
rows and columns ("row" then "column" ;-) is inconsistent with that for "x" and
"y" -- which can easily turn the code into a nightmare unless you take steps to
make the relationships explicit.  There are other examples, but that one is
probably sufficient...

   -- chris