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

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.

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.

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).

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

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!

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)

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.

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!"

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
}

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.