How is this "much better"? Once you understand the syntax of the ternary operator it's easy to read and easy to use.

Actually, it is much worse. Extra symbols certainly contribute to clutter and reduce readability.

More to that, in my opinion, "code flow" in functional languages is completely broken.

I have to remind myself how to read it every time I encounter it, and C and C++ are my dominant languages.

Better yet, you can do stuff like

  value = if (test) {some_value * multiple}
          else if (test2) {second_value}
          else {false_value}

which falls in a straightforward way out of the if/else syntax, which the language authors have put a lot more thought into than the rarely used ?: syntax.

How about formatting the ternary thusly:

  value = test
    ? (some_value * multiple)
    : false_value;

To match, it would have to be:

  value = test ? some_value * multiple
          : test2 ? second_value
          : false_value;

Which, you know, isn't that bad. But it looks really weird since people don't expect you to use ternary that way, while multi-part if statements are fairly normal.

That's basically the same syntax but with keywords. How is it 'much better'? And if you're doing something complex like nested ternary (please don't) you can use () to mark sections just as well as your method uses {} to mark sections.

it's better because 1) it falls out of the regular semantics of the language. it's just a regular if expression. it's a consequence of a more elegant and unified design, in other words. that ternary syntax by comparison is ad-hoc. to begin with, it's the only ternary operator in those kinds of languages. (thus people call it "the" ternary operator). it shows poor design restraint, imo

2) it's not punctuation. a ternary expression is a 3-input mapping to begin with. punctuation only makes it noisier.

>nested ternary (please don't)

Eh, if you use whitespace effectively it is perfectly readable. Moreso than the alternative, IMO.

Yep. My thinking exactly. Easiest thing to read is a table. Always :)

A table is fine, but the equivalent of 'else if' isn't true nesting. I meant making an elaborate tree, which should not be squished into a single statement unless you have a really good way of organizing it.

That's what I meant, as well :-)