Summary

The website content advocates for replacing nested if statements with guard clauses to improve code readability and maintainability, and it provides a step-by-step guide on how to refactor nested ifs into guard clauses.

Abstract

The article "Why You Need To Stop Using Nested If Statements" emphasizes the importance of avoiding complex nested if statements, which can lead to difficult-to-read and maintain code. It presents guard clauses as a cleaner alternative, where each condition is checked in sequence with an immediate return if the condition is not met. This approach prevents deep nesting and simplifies the code flow, making it more linear and easier to understand. The article illustrates the transformation process from nested ifs to guard clauses, detailing the steps to incrementally refactor the code. It also suggests the use of tools like the JavaScript Booster extension for Visual Studio Code to facilitate the inversion of if statements. Furthermore, the article discusses how to handle cases where actions need to be taken after condition checks by splitting logic into multiple functions, thus adhering to the DRY principle and implementing a chain of responsibility pattern. The overall message is that by adopting guard clauses, developers can write more maintainable and cleaner code.

Opinions

Nested if statements are depicted as a "typical use case" for validating data, but the article strongly advises against this practice, labeling it with a "Don’t do this!" warning.
The article expresses a clear preference for guard clauses, highlighting their ability to make code "much cleaner" and avoid the "mess" associated with callback hell.
The use of the JavaScript Booster extension is recommended as a practical tool for developers to simplify the process of refactoring if statements in Visual Studio Code.
The author believes in the DRY principle and suggests that guard clauses can help maintain this principle by reducing code repetition through the use of separate functions for each guard clause.
The article promotes the idea that guard clauses contribute to a "chain of responsibility pattern," which is beneficial for separating concerns and preventing excess nesting in code.
The article concludes with key takeaways, reinforcing the opinion that guard clauses lead to more readable, maintainable, and linear code compared to nested if statements.

Why You Need To Stop Using Nested If Statements

Typical use case for nested ifs: Validating data…

Don’t do this! 👇

There’s a better way:

See how much cleaner it is? Instead of nesting ifs, we have multiple if statements that do a check and return immediately if the condition wasn't met.

In this pattern, we can call each of the if statements a guard clause.

If you do a lot of Node.js, you’ve probably seen this flow in Express middleware:

It’s much better than this, right? :

You never go beyond one level of nesting. We can avoid the mess that we see in callback hell.

How to convert nested ifs to guard clauses

The logic for this for doing this is simple:

1. Find the innermost/success if

Here we can clearly see it’s the cond3 if. After this, if we don't do any more checks and take the action we've always wanted to take.

2. Invert the outermost if and return

Negate the if condition to put the else statements' body in there and add a return after.

Delete the else braces (keep the body, it still contains the formerly nested ifs, and move the closing if brace to just after the return.

So:

3. Do the same for each nested if until you reach the success if

And then:

And finally:

I use the JavaScript Booster extension to make inverting if statements in VS Code much easier.

Check out this article for an awesome list of VSCode extensions you should definitely install alongside with JavaScript Booster.

Tip: Split guard clauses into multiple functions and always avoid if/else

What if we want to do something other after checking the data in an if/else? For instance:

In this function regardless of cond1's value, the 'after cond1 check' the line will still print. Similar thing for the cond2 value if cond1 is true.

In this case, it takes a bit more work to use guard clauses:

If we try to use guard clauses, we’ll end up repeating the lines that come after the if/else checks:

Because the lines must be printed, we print them in the guard clause before returning. And then, we print it in all(!) the following guard clauses. And once again, in the main function body if all the guard clauses were passed.

So what can we do about this? How can we use guard clauses and still stick to the DRY principle?

Well, we split the logic into multiple functions:

Let’s apply this to the Express middleware we saw earlier:

In a way, we’ve replaced the if/else statements with a chain of responsibility pattern. Of course, this might be an overkill for simple logic like a basic Express request middleware, but the advantage here is that it delegates each additional check to a separate function, separating responsibilities and preventing excess nesting.

Key takeaways

Using nested ifs in code often leads to complex and hard-to-maintain code; Instead, we can use guard clauses to make our code more readable and linear.

We can apply guard clauses to different scenarios and split them into multiple functions to avoid repetition and split responsibilities. By adopting this pattern, we end up writing cleaner and more maintainable code.

Every Crazy Thing JavaScript Does

Just when you thought you knew all the quirks. Avoid painful bugs and save valuable time with Every Crazy Thing JavaScript Does, a captivating guide to the subtle caveats and lesser-known parts of JavaScript.

Get a free copy here today.

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go:

Be sure to clap and follow the writer ️👏️️
Follow us: X | LinkedIn | YouTube | Discord | Newsletter
Visit our other platforms: Stackademic | CoFeed | Venture | Cubed
More content at PlainEnglish.io