On the contrary. I prefer<p><pre><code> for (var i = 0; i < arr.length; i++) {
arr[i] = foo(i) ? bar(i) : baz(i);
}
</code></pre>
to<p><pre><code> for (var index = 0; index < array.length; index++) {
if (foo(index)) {
array[index] = bar(index);
} else {
array[index] = baz(index);
}
}
</code></pre>
in every way, including for readability.<p>The example is trivial but instructive. Each line in the second version is arguably more readable (in isolation) than its counterpart in the first, yet the verbose version as a whole imposes a longer time-to-comprehension on the reader — especially if you allow for the ability to grok idioms at a glance that one inevitably acquires after working with a given language or system for some time.<p>In my experience this argument becomes increasingly compelling as one applies it to more complex programs. What the naive notion of "readability" fails to account for is the compounding complexity tax of verbosity. It's a bit like analyzing the profitability of a trading system without considering transaction costs.<p>One more thing, with apologies for this being patronizing: an infatuation with an explicit spell-everything-out standard of readability seems to be a rite of passage on the path to programming maturity. I certainly went through it. I remember laughing uproariously at some of P.J. Plauger's (very tight and regular) library code years ago. I even remember shouting something like "if a programmer working for me ever wrote code like that, I'd fire them!" I literally did not know what I was talking about.