[gruseom]

On the contrary. I prefer

  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.

[benaiah]

He explicitly mentions that short ternary expressions like this are fine. My rule of thumb is that if it fits comfortably on one line, it's fine to use the ternary. (Of course, my real rule of thumb is to use CoffeeScript in the first place, but that's not always an option.)

[gruseom]

You're right and that's a fair point, but the argument still applies. The OP takes it as obvious that his rewritten jQuery snippet is better. In fact it's far from obvious, and learning the sense in which it's far from obvious is (in my experience) an important milestone, after which one stops arguing naively about readability and starts thinking more about the intelligibility of whole programs. If composed ternaries are an idiom that jQuery employs to do certain things compactly and repeatedly, that convention may well make it easier to understand jQuery. And that is what matters—not helicoptering into arbitrary bits of code.

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.)

[benaiah]

You make great points, and I think you're right. While I think the OP's advice is appropriate for most situations, particularly in general JavaScript code you have to share with other developers, jQuery's use of it is probably entirely appropriate. I skimmed the article, and by the end, I was already starting to grok how they were using the ternary at first glance - and, as others have pointed out, they may have more important considerations, such as execution speed, driving this usage.

Tangentially, I think his point about the descriptive variable names is far more important than avoiding if...else aliases (though it's not an original point, and the examples he shows are appropriate uses of short variable names).

I didn't think you were particularly patronizing. If you were, then I didn't mind.

[msoad]

CoffeeScript is not even close!

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(...