Chapter 1 - Understanding the Impact of Code Structure

What if I told you that eliminating the use of the else statement could enhance your coding skills and lead to higher quality code?

Let's face it… while we strive to adhere to coding standards and best practices, we are still human! Each of us brings unique preferences, backgrounds, and experiences that shape our coding style, making it distinct from our peers. This "style" often comprises subtle choices, such as opting for a ternary operator instead of a traditional if statement for straightforward checks, or favoring explicit function declarations over arrow functions. At times, these preferences verge on guilty pleasures.

Like everyone else, I have my coding inclinations, and as suggested by the title of this article, there's one particular habit I want to discuss: I refrain from using the else statement! ❓ Why is that?

The answer is straightforward: my code improves without it! I recognize I'm not alone in this perspective, but for those curious about my aversion to a fundamental component of programming, allow me to explain:

We can identify three common code smells often associated with the else statement:

1. The first smell pertains to complex conditions; if a condition is convoluted, the else statement becomes even more intricate, requiring the reader to mentally invert the condition.
2. The second smell is linked to the visibility of the condition itself. If the "then block" contains an excessive number of lines, it becomes easy to lose track of the original condition.
3. Lastly, the third smell arises when nested if-else blocks appear, which can quickly become extremely difficult to read.

In each of these instances, refactoring the code to eliminate the else statement results in clearer and more readable code. This leads me to ponder — what if the else statement had never existed? Would our coding world be improved without it? ❌

Short answer: Yes.

Long answer:

The issue isn't with the else statement itself; it's about how we use it! If we revisit those three significant "smells," it becomes evident that the fundamental problem lies not in the else statement, but in the overall if-else structure that, when misapplied or overused, can quickly devolve into chaos.

Restricting yourself from employing the else statement is merely a technique to better organize your code, compelling you to extract code into separate functions—a practice that is beneficial regardless of your stance on else.

So… what if we lived in a world devoid of "else"?

Let's establish this: the else statement is often unnecessary! A world without else is not only feasible but preferable!

Even with countless conditions in our code, two scenarios arise for an if-else statement: when there’s no code to follow the if-else, and when there is.

First scenario: No code follows the condition.

In this case, employing the "Return Early" strategy is effective.

Second scenario: Code executes regardless of the condition's outcome.

Here, extracting the if-else block into a separate function proves beneficial. This is known as the "Extract Method" pattern.

You can also apply these methods to nested if-else statements, combining Return Early and Extract Method.

Let’s explore a practical example for clarity:

First scenario:

Is the else branch necessary here? Clearly not! We can simply Return Early, eliminating the else statement entirely. In fact, we don’t even need the if statement, as returning "number % 2 === 0" suffices. Hence, the subsequent code serves as an implicit else branch, resulting in clearer and more concise code.

Second scenario:

Again, is the else branch required? Absolutely not! Not using the else branch actually improves the quality of the code. Previously, the function performed two tasks:

• Constructing the message content.
• Triggering the API to send a notification.

Now, the message creation is assigned to a dedicated function, leading to more readable and better-structured code.

👋 In conclusion

Thank you for engaging with this article! I’d love to hear your thoughts, so please leave a comment. ❤️

To clarify, I don’t have an issue with the else statement, nor am I suggesting its complete avoidance. My main point is this: if you find yourself lost in a condition, consider refactoring to eliminate else branches—this will enhance your code quality by encouraging best practices and modularizing complexity into distinct functions. If you're comfortable with your use of else, that’s perfectly fine too! 😉🙆🏻‍♂️

About the author

References

Else Considered Smelly: http://wiki.c2.com/?ElseConsideredSmelly

Return Early Pattern: Extract Method Animations

The animations are created using slides.com.

Explore more content at PlainEnglish.io. Sign up for our free weekly newsletter. Follow us on Twitter and LinkedIn. Join our Community Discord and engage with our Talent Collective.

Chapter 2 - Strategies for Becoming a Better Developer

Explore 10 effective techniques to enhance your skills as a developer, focusing on best practices, productivity, and personal growth.

Discover 5 key ways to elevate your development skills, emphasizing practical approaches and mindset shifts.