Beyond Else: Writing Clean and Maintainable Code

For my first blog, I wanted to start with a bold statement. How else could I capture the very scarce resource of time? In the next few minutes, I want to explain why we would be better off without an else.

Simple Value Assignment

First I want to show cases where assigning a value to something is based on a single if and else.

let x;

if (condition) {
  x = 0;
} else {
  x = 1; 
}

Now, imagine the same thing but without the else statement. Can you already imagine how that would look like?

Take a moment to think about it! I've even given you some space to ponder, complete with pictures of dogs and cats!

const x = condition ? 0 : 1;

While you might think: "hey, that is somewhat an else!" I would argue that the ternary operator is not an else statement. It works the same way but differs greatly in semantics. And if we compare the two examples, the second is a lot more digestible for our brain.

Digression to the coalescence operator

I want to go into more detail based on the ternary principle. We can improve readability by using the coalescing operator. A few languages use this principle. It is quite powerful. In null and undefined checks, we can simplify the ternary operator even more. First, we need to specify the top condition as the following:

const x = condition !== undefined ? condition : 1;

In coalescence style we can simplify this.

const x = condition ?? 1;

Assignment chains also work extremely well.

let x = undefined;

x ||= f1();
x ||= f2();
x ||= f3();

If f1 returns something not false, then x will be that value. Otherwise, the chaining will fall back to f2 and so on. This allows to make complex assignations without compromising on readability because you need to use an else statement.

Complex Value Assignment

There is still a huge chunk of code that cannot be maintained without an else, if we only use the methods described until now. These are all the situations in which we assign a value in a more complex case.

let x;

if (condition) {
  const a = function1();
  const b = function2(a); 
  const c = function3(a, b);
} else {
  x = 1;
}

Using the ternary example this case would look horrendous.

const x = condition ? function3(function2(function1()), function1()) : 1;

First things first, this is not performant, since calling function1 twice results in repeating the same calculation. This is no problem when the function is small, but I/O Operations would be a huge blow to the performance of the code. All that, to not improve the readability in the slightest. This is where encapsulation comes to the rescue.

function calcX(condition) {
  if (condition) {
    const a = function1();
    const b = function2(a);
    return function3(a, b);
  }

  return 1;
}

const x = calcX(condition);

This approach relies heavily on the concept to use an immutable variable wherever possible. I highly recommend using const variable, because the value cannot change unexpectedly. Now, we don't know what happens during the assignment process, but in most cases we don't care and a describing name is enough. In the rare case, where calcX doesn't work correctly or undergoes some changes, it is more straight forward to go into the function and fix the problem in a more focused manner, without the distracting code around. It's all about setting the right focus in your code, so your brain doesn't have to do acrobatics early in the morning.

Finally, I want to suggest using switch instead of if, if else and else.

So, I should never use an else?

No, these guidelines cover maybe 99% of cases. The other 1% don't need an else but are more readable when using one. Always strive for the most readable solution and think for yourself: "What looks more readable for myself?". Code often goes through many iterations until it's optimal, both for readability and performance. Ideally, you have code snippets from the past, where you can check if you can read them easily. If not, then perhaps rework your approach. Keep in mind, that code is always simpler to write than to read.

I would enjoy to read your thoughts on the topic and if you like my ideas don't wait and try to incorporate them in your code now!

You can find a more detailed version here and general information about myself here.

Thank you all for reading