[cgmorton]

Eh. Your construction is perhaps easier to understand if you've never used the language, and are trying to learn it just by reading arbitrary source code. But who writes code for such a person?

You might as well spell out:

int iterator; for (iterator = ...

But everybody uses 'i', because it's faster and simpler, takes less time to read, and doesn't fill up your screen so that surrounding elements can be easily associated (e.g. a[i].do(x) vs myArray[iterator].doCoreFunction(element_x) <- yuck)

[jdmichal]

I write all the time:

    for(int index = 0; index < collection.size(); ++index)

I don't believe in the philosophy of saving seconds of programmer time at the cost of understandability, especially when the latter is increasingly more important. Also, calling it "index" makes it really obvious when you're possibly using it wrong (ie, as anything other than an index). My version of your latter example would never look so ugly, because I would never ended up with such badly worded things in the first place. (Who puts domain functions on their model objects?)

    for(int index = 0; index < things.size(); ++index) {
        final Thing thing = things.get(index);
        businessUnit.doSomething(thing);
    }

[sophacles]

At some point this construction has the opposite effect of your stated goal. Programming languages have their own syntax, grammer, and idioms. Working with those isn't so much about saving time, but about making clear statements. I'm not certain how calling your variable index is better than calling it i - the entire fact that it implied in the construct.

I'm not disagreeing that having decent names is a good idea, just that idioms and convention convey a ton of meaning. For instance if any of my team ever did:

   def func(self, a, b, c): ...

There would be a problem. (most of the time anyway...)

By analogy: do you always refer to people strictly by full name (that is never calling Robert Smith by Bob, rob, Robert, etc)? Do you always refer to your vehicle as "my $Year $Make $Model" rather than "my car"? Why not? Because it is strictly clearer and easier to do so, with less ambiguity and chance for confusion. I'm guessing not, because the language you speak in has idioms and constructs that allow shortening this, and understanding is not lost.

Basically my point is that assuming the reader of your code is a complete neophyte, with no understanding of common idioms is largely ridiculous, and potentially harmful to the actual neophyte+(small amount of experince) folks because they wonder why the common pattern is not being followed... asking "why is this different? it must be special, not just a for loop..."

[jdmichal]

But people also write:

    for(int i = 1; i <= n; ++i)
        sum += i;

This would look immediately wrong if i was actually index.

Also, your analogy to linguistic concepts is bad. Sure I call people Bob, but I'm also not expecting to have to reread my conversation with them half a year later and modify it to say something else instead. Also, those linguistic concepts are not idioms. They are just alternate names and indexical constructions, respectively. An idiom is something like "What's up?", where the literal meaning of "what is up" is not intended, but rather another meaning that is completely lost unless you are in the know.

[mcsmash]

Using the variable names i/j/k for loops is such a widely used convention that IMHO it doesn't really mater for a lot of people. Virtually everyone I know will read "array[i]" and know exactly what's going on.

And believe it or not, those variable names aren't arbitrary. They hearken from the ancient times: http://programmers.stackexchange.com/a/86911

[eropple]

I tend to use

  for (auto iter = something.begin(); iter != something.end(); ++iter)

in C++. It's an abbreviation, but a clearer one (both to me and to the reader of my code). An integer is (to me) an index, not an iterator, so I'd kind of call that misleading anyway.