Nested ternaries aren't bad, just misused

The argument against nested ternaries is that they can make code more difficult to understand. But they can make code easier to understand if they are wielded properly. Instead of banning nested ternaries, require that they are formatted such that each line has a single condition and a single result, with the catch-all at the end:

// bad
const foo = maybe1 > maybe2
  ? "bar"
  : value1 > value2 ? "baz" : null;

// good
const foo =
  maybe1 > maybe2 ? "bar"
  : value1 > value2 ? "baz"
  : null;

This is similar to a switch statement that always breaks. With this pattern, it’s impossible to get lost in nested contexts. Once you’ve ruled out a line applying to the case you’re considering, you can safely forget it. It’s easier to understand than the solutions provided by the style guide right now, and also saves a memory allocation.

Here are some other examples where this pattern improves code:

// bad
let result;
if (operator === ‘+’) {
  result = left + right;
} else if (operator === ‘*’) {
  result = left * right;
} else if (operator === ‘-’) {
  result = left — right;
} else {
  result = left / right;
}

// good
const result =
  operator === ‘+’ ? left + right
  : operator === ‘*’ ? left * right
  : operator === ‘-’ ? left — right
  : left / right;

• Less code.
• Prefers const over let.
• Avoids side effects (i.e. assigning value of variable outside block scope).

// bad
if (conditionA) {
  outcome1();
} else if (conditionB) {
  if (conditionC) {
    outcome2();
  } else {
    outcome3();
  }
} else {
  outcome4();
}

// good
conditionA ? outcome1()
: conditionB && conditionC ? outcome2()
: conditionB ? outcome3()
: outcome4();

• Less code.
• Less cognitive load.

[ljharb]

First of all, things that are easily misused / are easy to improperly wield are bad.

A switch statement isn’t a good idea to use ever either, because you can easily forget to always break. In the future, switch statements will be discouraged by this guide as well. (Separately, memory allocation is irrelevant; JS is a memory-managed language, which means it’s not the developer’s business to think about it).

The pattern you’re suggesting still has the same issues with intuition about precedence, so it doesn’t address the problem. In particular, I don’t agree that any of your “good” examples are easier to read; you’re also abusing && for control flow. The if/else example is far better.

[okaybenji]

@mk-pmb Sure, you could write:

const getResult = (operator) => {
  if (operator === ‘+’) {
    return left + right;
  }
  if (operator === ‘*’) {
    return left * right;
  }
  if (operator === ‘-’) {
    return left — right;
  }
  return left / right;
};

const result = getResult(operator);

But this code is still much better:

const result =
  operator === ‘+’ ? left + right
  : operator === ‘*’ ? left * right
  : operator === ‘-’ ? left — right
  : left / right;

It’s easier to read and understand, takes less time to read and maintain, and has less surface area in which bugs can hide. The fact that it’s also much more performant is just the cherry on top.