As you say, list might be the best name for a variable if the use context is generic. The same with iterators and such. But you really have to think ahead to keep the names consistent, complicated names work against consistency.
List<Foo> foos;
for (fooIndex = 0; fooIndex < foos.length; ++fooIndex) {
Foo foo = foos[fooIndex];
List<Bar> bars = foo.bars;
for (barIndex = 0; barIndex < bars.length; ++barIndex) {
Bar bar = bars[barIndex];
}
}
That, of course, is assuming you even need the indexes. Otherwise you get this:
foreach (Foo foo in foos) {
foreach (Bar bar in foo.bars) {
}
}i and j really make more sense (as i and j) when used in their more mathematical connotation: indexes into a multidimensional array/object.
for (i = 0; i < thing.length; i++) {
for (j = 0; j < thing[i].length; j++) {
thing[i][j]; // this is very close to the mathematical use of indexes
}
}
i and j would be poor fits for your first example because they don't index into the same thing anymore. You've introduced additional levels of indirection, to rewrite your first example using i and j (and illustrate why this is an awkward construct):
for (i = 0; i < foos.length; i++) {
for(j = 0; j < foos[i].bars.length; j++) {
foos[i].bars[j];
}
}
=====
And of course, you're absolutely correct: foreach or equivalent is a better construct. It states the intent of the code, rather than the how of the code. This keeps your code closer to the semantics of your problem specification.