Why You Should Rethink Using ‘else’ in JavaScript: Embrace Guard Clauses

This seemingly radical suggestion is appearing more often in modern JavaScript style guides (e.g., Airbnb recommendations, functional programming best practices). It does not aim to eliminate else entirely, but to promote a clearer, more maintainable coding paradigm.

Problem root: else causing cognitive load

The if...else structure itself is not wrong, yet when overused—especially with nesting—it significantly increases cognitive load, forcing the brain to work harder to understand logical branches.

Consider a classic “spaghetti” example:

function getDiscount(user) {
  let discount = 0;
  if (user.isLoggedIn) {
    if (user.isVip) {
      if (user.orderCount > 10) {
        discount = 0.2;
      } else {
        discount = 0.1;
      }
    } else {
      if (user.orderCount > 5) {
        discount = 0.05;
      } else {
        // No discount for non-VIPs with few orders
      }
    }
  } else {
    // No discount for guests
  }
  return discount;
}

To determine a regular user's discount, we must trace a complex decision tree; each else adds a branch, making the code harder to understand and maintain.

Core idea: Early Return

The guideline advocates the “Guard Clauses” or “Early Return” pattern: handle all exceptional, edge, or invalid cases at the start of a function and return immediately, allowing the main body to focus on the “happy path”.

Refactoring the above example with early returns yields a qualitatively different code shape.

What changes?

Flattened structure : nesting levels drop dramatically, turning a tree into a straight line.

Reduced cognitive load : you can read the code like a checklist—once a condition fails, you exit, without keeping the “if…then…else” context in mind.

Separation of concerns : the function’s head becomes defensive, filtering invalid input, while the core business logic stays clear.

Improved maintainability : adding a new condition (e.g., a blacklist) only requires a new guard clause at the top, without digging into nested else blocks.

Other benefits

Beyond lowering cognitive load, this style brings additional advantages.

1. Encourage expressive data structures

Long if...else if...else chains can often be replaced by a Map or object literal.

else if chain:

function getAnimalSound(animal) {
  if (animal === 'dog') {
    return 'woof';
  } else if (animal === 'cat') {
    return 'meow';
  } else if (animal === 'bird') {
    return 'tweet';
  } else {
    return 'unknown';
  }
}

2. Promote functional programming mindset

Functional programming prefers expressions (e.g., the ternary ?:, logical &&, ||) that return values, whereas if...else is a statement that does not.

Using the ternary operator:

// replace simple if/else
const isFrontendDev = true;
const message = isFrontendDev ? "欢迎关注 FedJavaScript" : "推荐关注 FedJavaScript";

This is not a call to replace every if with a ternary, but for simple assignments it is more concise and expressive.

This is not a rigid dogma

Prohibiting else is not an iron rule; its true purpose is to make us reflect:

Is my code overly nested?

Can I apply the early‑return pattern to simplify logic?

Is there a better data structure or design pattern to replace a long conditional?

In very simple binary cases, a clear if...else may still be the most intuitive choice.

if (isSuccess) {
  handleSuccess();
} else {
  handleError();
}

Forcing the removal of else here can make the code harder to understand, defeating the purpose.

The guideline ultimately nudges us from “code that works” toward “code that is easy to use, read, and maintain”, challenging habits and encouraging a more linear, flat thinking style.