> You see the problem though, I need to try it and practice it to see how simple and clear it is.
You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table.
> Why do I want that?
To add to the other poster: the more context you can fit on your screen, the less scrolling, jumping you need to do to understand a program's behaviour. Compactness that doesn't sacrifice readability speaks for itself. The code sample we're discussing is compact and very readable.
>It literally takes 5 seconds to understand the idiom
I understand how ternary operators work. It's still hard to read if you inline multiple ternary operators the way OP suggested is easy. It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does.
In fact, it is obviously so confusing that to make it work someone suggested the introduction of white-space and multiple lines, as follows:
return
(a < b) ? -1 : // a smaller
(a > b) ? 1 : // a greater
0; // equal
And they still got it subtly wrong, because the semantics of their 'fix' makes it seem like it is the equivalent of:
if(a < b)
return -1;
else if(a > b)
return 1;
else
return 0;
which isn't quite true. It's actually:
if(a < b)
return -1;
else
if(a > b)
return 1;
else
return 0;
Will this make a difference in this case? No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code.
> It's still hard to read if you inline multiple ternary operators the way OP suggested is easy.
I disagree. The ternary version is much easier to read than your if-else. If-else statements can feature compound statements and side-effects where the ternary version is simpler because it only returns a value. There are fewer corner cases to consider.
> It adds cognitive complexity, and hides bugs because your brain will fill the details on what it assumes it does, versus the subtleties of what it actually does.
It adds no complexity. It's significantly easier to understand than if-else.
> which isn't quite true. It's actually:
Right, there's literally no semantic difference between those two.
> No - but there is a subtle semantic difference that you have to stop to consider when you're scanning this code.
You really don't. There's nothing special to consider, no corner cases. It's literally condition-on-left-value-on-right.
You need to practice it to overcome your skepticism resulting from your ingrained habits that prejudice you against it, not because it's inherently unreadable. It literally takes 5 seconds to understand the idiom: conditions/guards on the left, value on the right. It's essentially a truth table.
> Why do I want that?
To add to the other poster: the more context you can fit on your screen, the less scrolling, jumping you need to do to understand a program's behaviour. Compactness that doesn't sacrifice readability speaks for itself. The code sample we're discussing is compact and very readable.