I just wrote a nested ternary in my code

I have become that which I hate.

At least put them on separate lines and use descriptive variables.

You have to do that when you use stupid language designs that only allow functional code, like OpenSCAD.

As @Demolishun said, use variables for conciseness.

But why?

Ternary: Ok.

Nested ternary: Go fuck yourself, instant reject.

Nested ternary with alternating boolean states...

$true = false;

$is_true = $true ? false : ($true ? !$true : $true);

var_export($is_true);

I hope someone shoves a burning stick up your rectum so the shit stays inside where it belongs.

That true false though is absolutely horrible!

well. 💩.

@TheCommoner282

if (cond1) {
A
} else {
if (cond2) {
B
} else {
if (cond3) {
C
} else {
if (cond4) {
D
} else {
E
}
}
}
}

Thats what the syntax sugar is hiding.

Which is the reason why the syntax sugar of a ternary is bad - if "misused".

A simple if else never hurts. That's not the discussion.

A nested if else though - that's always the trouble. You can make it look nicer by utilizing ternary instead of if / else...

And maybe applying a nicer formatting like you did.

But it's still a complex logic expression, no matter how much you try to sugar coat it.

If you write that nested stuff inside a function and utilize returns, it gets this...

if (cond1) {
return A
}
if (cond2) {
return B
}
if (cond3) {
return C
}
if (cond4) {
return D
}
return E

No nesting. No complex logic.
Syntax sugar is completely eliminated.

I always prefer the function style, cause it makes it blatantly easy to spot what happens and why.

Your formatting seems nice, but it "shadows" the fact that all these expressions are evaluated one after another.

Refactoring nested stuff is a pain in the butt. Early return functions make it way more maintenable and reduce the danger of regressions, too.

Extract that shit out !

@TheCommoner282

... Yes, but I think you're wrong in that part. E.g. I know a lot of people who don't like *early returns* because they have trouble with visualizing a control flow.

For them if / else is cleaner, despite the return in it, like this:

if (A) {
return A
} else {
return B
}

That would fall in your category of untrained brain imho. Not being able to visualize and understand control flows is definitely a lack of a required skill for a programmer.

Ternaries on the other hand are just writing complex stuff in short - it doesn't simplify things.

It's painting over mold to put it into a metaphor. Just cause the mold is now white, it doesn't change the fact it's mold, that will regrow and pose a problem.

Or to point out the imho flaw in your logic: when we have to train people to understand complex stuff just cause we want to write it complex, despite simpler solutions being available, we're wasting resources to cater for a problem that could be solved easier.

Hence the painting over mold metaphor: Yes, you can paint over mold. But you will have to do it over and over again, as the paint doesn't solve the problem of the mold growing. It just gives it a nicer color.

TLDR:
The reason why I'm not fond of nested ternaries is that it leaves the original problem, the complexity, despite simpler solutions being available.

Make it more verbose and less complex&concentrated?

@IntrusionCM error 404

Try the python walrus operator, see how much hate you get then.

@IntrusionCM If your function gets inlined, it results in the exact same assembly or bytecode as the nested ifs or the ternary if the empty labels in those are eliminated. If it doesn't get inlined, you just introduced a function call where none was needed.

Speaking of unnecessary syntax sugar.

It's pretty clear to me that each branch implies the falsehood of all previous ones, which in turn implies that they're all evaluated one after the other. I think the complexity here is very plainly out in the open, as it is in an if tree, a switch-case, or a function with early returns. The core difference to me is that this is

- not too syntax heavy unlike the if tree
- able to return a value unlike the switch or the if
- colocated with the context unlike the function

@Raidhunters Not sure what you mean.

@lorentz

https://en.m.wikipedia.org/wiki/...

Syntactic sugar is explicitly meant in a context of a programming language… not a binary / AST representation or assembly.

That's the whole point of the discussion... Not what a compiler makes out of it, but what human can make out of it. Two completely different things.

The programmer is the one who is prone to misunderstand / misinterpret the ternary constructs, especially when they're complex, and introduce regressions. The compiler / interpreter isn't relevant in this discussion at all.

I don't think I'm arguing on a subjective bias either - the anti pattern of nested conditions has many forms, plus many have fallen into the pit of misinterpretation of nested conditions.

Many static code analysis tools see nested ternary as a *major* code smell.

https://rules.sonarsource.com/javas...

Sonar Lint as one example.

I can understand why, but honestly, discussion is moot at the point when we're talking "but my compiler does pretty things which is why I can write however I want".

@IntrusionCM A ternary has a value, as such, I never considered it syntax sugar for an if statement. If you really want to unify them, an if statement might be syntax sugar for a ternary with a discarded value, but even then an if can have a long body so realistically neither is syntax sugar and they're just different things entirely.

The rule you linked shows an example which falls into the unique special case where the result of the ternary is returned. This is in my opinion the only case where early returns are an actual substitute for a nested ternary.

Nested ternaries are error prone because complex logic is error prone, and the majority of programming challenges have a pattern that can be exploited to eliminate clusters of decisions.

They are inadvisable for the same reason deeply nested ifs or large sets of early returns are, none of these is an alternative to the others.

@lorentz

I'm not sure what languages you're talking about, I'd assume highly functional.

In my opinion, assignment of ternary to a variable is the most common ternary you find, a ternary which discards it's return value / calls e.g. a function instead is a pretty rare unicorn.

I'm not even sure how many languages allow that?

@IntrusionCM A lot of languages allow it because it acts as an expression-statement. The reason it's uncommon is that you can use an `if` instead.

But this is beside the point, I only mentioned it to show that ternaries aren't any less natural than if statements if you actually break them down into behavioral aspects instead of tautologically treating the if as a unit.

Isnt this something pattern matching would be good for?

@Wisecrack partially, yes.

But heavily dependent on language and capabilities.

As soon as the conditions become more complex, like "if func(obj1) or func(obj2)" it's moot.

@IntrusionCM I remember a few things from erlang and languages derived from it, and always loved the idea.

There is a case to be made that the syntax for ternaries could be cleaner.

But on the bright side nested ternarys beat a bunch of if statements, and temporary variables, which would otherwise make the code harder to grok anyway.

@IntrusionCM what in god's name is that abomination haha

@Tonnoman there were so many abominations in this thread...

Can u be more specific xD

@IntrusionCM my comment was written after reading your first comment... Now I dont even know anymore haha