Stop Using Else in Your Programs
A practical introduction to guard clauses
When I first began programming, I wish someone would have told me about a few different concepts to think about when writing my first website.
One of the mistakes I fell into when starting was overusing the else keyword when writing conditionals. This is something that I find plenty of others doing in their own code as well, so I thought I should shed some light on the topic.
A disclaimer; my view on this topic is purely subjective.
In some situations, you may not be able to apply this type of approach to your code. Sometimes, the solution is to use the else keyword. This post is to inform people of an alternative approach to structuring logic.
Guard Clauses
According to Wikipedia, a guard clause is a check of integrity preconditions used to avoid errors during execution.
Let’s break down that definition into layman’s terms. We perform a check of integrity preconditions (at the beginning of our code) to avoid any bugs during the main flow of our logic.
In the perfect flow (when validation is correct), we want the main logic of our program to be after all of the validation checks.
Let’s imagine that we run a website where we have a premium purchase area that is restricted to paying customers only and only open after 12 pm.
In an actual application, we would likely return some form of exception.
While this is an approach to flow through the conditionals, the else keywords become difficult to follow even when we only have a small number of them.
This is a trivial example of conditional logic but, out in the wild, imagine trying to navigate a class that has much more complex logic. Coding through this standard, in my opinion, is not sustainable and we should do better.
With guard clauses, we will want to follow this framework:
Taking that framework, we can restructure the previous code like the following:
In guard clauses, we typically invert the boolean expression to what we want to assert. If we want the user to be signed in to view this page, we want to check if they’re not signed in.
This approach captures the same exact logic flow but, in my opinion and in others as well, this is a much cleaner approach when tackling conditional logic.
Conclusion
When coding, we should always keep the question in-mind of: “How easy will this be to maintain 6 months down the line?”
Creating solutions to a problem at the current time is great. But what about in the future? Not building software with the future in-mind is silly.
It has personally caused me to entirely rewrite whole features from scratch because of how much technical debt I accumulated over time through numerous band-aid fixes.
Utilizing guard clauses will set your future self/team up for success for when new requirements are added to your program.
