DEV Community

Don’t ever use if-else. Use this instead

Tymek Zapała on October 25, 2024

Let’s talk about a coding trick that makes your code easier to read and keeps things organized: early returns. Lots of coders rely on if-else stat...

Read full post

Dima Vyshniakov • Oct 28 • Edited

Early returns are useful. But be careful. Now your logic critically depends on the order of if statements and existence of each of them (basically you have to rewrite blocks 3,4,5… if you remove block 2). Sometimes this approach can be hard to refactor.

More reliable way of doing this is to use some kind of mapping.

Tymek Zapała • Oct 28

Totally agree, mapping is great if you have lots of cases and don't want to be dependent on order.

However, early return is alternative to if-else, not the mappings :)

Dima Vyshniakov • Oct 28

It’s a transitive quality 🥹

Remo Dentato • Oct 27 • Edited

This is fine for just returning but it's not always ideal.

If you have common tasks that need to be completed at the end of the if/else chain you need to be careful:

  if (test_a)  do_someting_a(); 
  else if (test_b) do_something_b();
  else do_something_c();

  long_cleanup();
  return;

You can re-factor the end task in a function and call it in every branch. Except that if have any local variables you need to use for your cleanup, you have to pass it to the function.

Or you can write some "partial cleanup" code in every branch. There are options but you have to weight them.

In the end, use these "early returns" whenever they make the logic simpler to follow but do not forget that the key principle of structured programming ("one entry and one exit for any code block") is there for a reason, it keeps the entire code easier to maintain and modify.

Charles Roth • Oct 28

Yes... except "one entry and one exit for any code block" which is a largely a myth. It's useful for languages like C++ where you have to do cleanup (e.g. if you allocated some memory) at the end. But for more modern languages (Java, Python, etc.) that have automatic garbage collection, the "one return" has no particular virtue.

A series of guard clauses, each with its own return, is much easier to read and understand, compared to a single return for any entire method or function.

Tymek Zapała • Oct 27

If you need to do a cleanup after return then it means the function no longer has a single responsibility, I would refactor this.

Wizard • Oct 26

Nice tip for more cleaner code, I always use this guard clause in my code

Tymek Zapała • Oct 26

It really makes a difference, doesn't it

Wizard • Oct 26

100%, reducing code complexity, cleaner and readable, and easily understandable code

Ben Sinclair • Oct 27

It doesn't reduce complexity. If you return from a block inside an if then everything after it is equivalent to being in the else, so it's exactly the same from a code point of view.

It is, however, easier to read without the elses and if you keep your functions short and don't need to do anything with the values you've just set after the condition, then it's the way to go.

Ian Littlewood • Oct 29

The final generated code may be very similar, even identical, but when it comes to READING that code, reducing nesting most definitely DOES reduce complexity because it requires holding only a single state in mind. With nested conditions, it's necessary to hold all passed conditions up to that point.

Grant Riordan • Oct 26

Good tip for beginners. 🙌 if you’re looking for the term to explain what you’re doing here. It’s called a “Guard clause” as guards your code and short circuits it (returning early).

Tymek Zapała • Oct 26

Cool tip Grant, thank you!

Rey • Oct 31

title nowadays : 1 being creative the others duplicate. I'm sick of seeing any content started with "Don't..." "Stop..." they keep coming to my email like sent by the wisest man in the earth.
vuck yue.

Wafa Bergaoui • Oct 29

Stacking if-else statements can quickly become confusing, especially in larger functions. This approach not only makes the code cleaner but also easier to maintain. Thanks for sharing this helpful tip!

webbureaucrat • Oct 28

This is a good way to really maximize how imperative your code is. I much prefer expressive style.

If you don't like the nesting, you can always break it out into multiple functions.

function getDiscountMessage(user) {
    return user.isActive ? getDiscountMessageForActive(user) : `User ${user.name} is inactive.`;
}

function getDiscountMessageForActive(user) {
    return user.hasDiscount ? `Discount applied for ${user.name}!` : `${user.name} does not qualify for a discount.`;
}

The benefit here is you are syntactically guaranteed to have considered all cases, whereas imperative if without an else makes the else implicit instead of explicit and sets you up for mistakes if you or another maintainer need to change the code in the future.

(inb4: of course this is a contrived example and IRL I'd probably just have active and inactive users be completely different classes or something to avoid boolean flag code smell)

Amit Rastogi • Oct 27

How about when the perfect scenario logic also depends on certain conditions like -

//processing perfect scenario logic
if (condition 1) {
//process differently
}
else if(condition 2) {
//process differently
}
else {
//process differently here again
}

Diallo Mamadou Pathé • Oct 27

Hello,
It can be break like this using strategy design pattern too.

// Step 1: Define the Strategy Interface
class DiscountStrategy {
getDiscountMessage(user) {
throw new Error("This method should be overridden by subclasses.");
}
}

// Step 2: Implement Concrete Strategies
class ActiveWithDiscountStrategy extends DiscountStrategy {
getDiscountMessage(user) {
return Discount applied for ${user.name}!;
}
}

class ActiveWithoutDiscountStrategy extends DiscountStrategy {
getDiscountMessage(user) {
return ${user.name} does not qualify for a discount.;
}
}

class InactiveUserStrategy extends DiscountStrategy {
getDiscountMessage(user) {
return User ${user.name} is inactive.;
}
}

// Step 3: Implement the Context Class with a Lookup Table
class DiscountMessageContext {
constructor(user) {
this.user = user;
this.strategy = this.selectStrategy();
}

// Lookup table to map conditions to strategies
selectStrategy() {
const strategies = {
'activeWithDiscount': new ActiveWithDiscountStrategy(),
'activeWithoutDiscount': new ActiveWithoutDiscountStrategy(),
'inactive': new InactiveUserStrategy()
};

// Determine the key based on the user's properties
const key = this.user.isActive 
  ? (this.user.hasDiscount ? 'activeWithDiscount' : 'activeWithoutDiscount')
  : 'inactive';

return strategies[key];

}

getDiscountMessage() {
return this.strategy.getDiscountMessage(this.user);
}
}

// Usage
const user = { name: "Alice", isActive: true, hasDiscount: true };
const discountContext = new DiscountMessageContext(user);
console.log(discountContext.getDiscountMessage()); // Output: "Discount applied for Alice!"

Paul / Appurist • Oct 28

This is common practice for me (and I've been coding professionally for over 40 years now). However, I will take exception to your title, which argues against a fundamental feature of most languages. I thought you were going to argue for ternary operators everywhere. ;)

Instead, I think what you're saying is "replace if-else with if-return where possible" to clean up code. I'm definitely with you on that.