All projects should take the same approach and stick to one set of Coding Standards. This solves many common problems, especially when projects which have more than one developer.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand” - Martin Fowler
There are some things that are not covered by Coding Standards which are mostly subject of preference and not directly related to format of the code.
While, Coding Standards are strict guidelines that we should be stick to, relating to the way code is written and its readability, Best Practices are recommendations that may help with security, performance, or architectural patterns that are solutions to a commonly occurring problems.
Often these best practices are left solely on the developer to decide. One such best practice is “return early”.
This is another in a series of Best Practices that have served me well over the years and have stood the test of time, ones that I use or refer to on a regular basis.
What is an early return?
An early return, or “return early” is an approach to keep readability in functions and methods.
It is always considered a wise choice to return early if simple conditions apply that can be checked at the beginning of a method.
Why return early?
The motivation behind this is to avoid nesting too deeply and return early instead.
Too many if-else statements can make your code hard to follow. Explicit is better than implicit.
It's better to return early, keeping indentation and brain power needed to follow the code low.
Example
Here’s an example.
Bad: Not returned early
To keep readability in functions and methods, it is wise to return early if simple conditions apply that can be checked at the beginning of a method.
<?php
function foo($bar, $baz)
{
if ($foo) {
// method logic goes here
return $calculated_value;
} else {
return null;
}
}
?>
Good: Returned early
It's better to return early, keeping indentation and brain power needed to follow the code low.
<?php
function foo($bar, $baz)
{
if (!$foo) {
return null;
}
// method logic goes here
return $calculated_value;
}
?>
Why wouldn’t you return early?
Functions that exit at multiple places using return statements may be confusing and can be hard to refactor.
The exception to this is usually when using early returns for type validation or an input mismatch.
When trying to keep it simple, you may find yourself torn as to what is more simple. Less code or more verbose code? Do whichever makes it easier to maintain.
What if we don't have time? We often find ourselves compromising on quality in order to deliver value sooner, this is fine initially but over time it becomes much more difficult to maintain.
Conclusion
There’s usually good reason to return early and rarely an exception.
My view is that returning early is a best practice that you should adopt as a style guideline. I tend to recommend it as I find it makes the code much easier to read and keeps methods short.
In summary, anything that helps to make your code more human readable is a good thing, including returning early.
Top comments (2)
Nice post. Agree with everything you said and have the same preferences.
Thanks for your good ideas about clean code. I will use of it to my code be readable more.