for (var i = 0; i < arr.length; i++) {
arr[i] = foo(i) ? bar(i) : baz(i);
}
to for (var index = 0; index < array.length; index++) {
if (foo(index)) {
array[index] = bar(index);
} else {
array[index] = baz(index);
}
}
in every way, including for readability.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.
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.
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.
In terms of lines of code—an imperfect metric but a useful one—his rewritten example is twice as long. That may seem like a small price to pay for an easier-to-understand snippet in isolation but if you start thinking about a complex system as a whole, and consider how complexity compounds as programs grow, that intuition changes considerably.
(I'm done being patronizing now.)
It can't even understand this code which is legit but horrible
a = ()-> Math.random() * 1000 - 500
b = ()-> Math.random() * 1000 - a()
c = a == b ? a() < 0 ? a(b()) : b() : a(a())
http://coffeescript.org/#try:a%20%3D%20()-%3E%20Math.random(...Also if I was going to write it 'cleaner', I would find something like http://pastie.org/7118990 cleaner.
(but in essence I agree)
I agree with you that use of the ternary operator, when not used properly, can obfuscate some code that could be simplified with if/else operators. But, jQuery has chosen to forgo readability for performance (and for good reason IMO).