Published: May 02, 2022 • Updated: August 11, 2023 • 4 min read
A programming style I try to practice could be described as: “there should be only one way out of a function.” Early returns can often cause more confusion than they’re worth. When possible, I avoid them in favor of a single return.
Here’s a demonstration of this style.
Imagine a function that takes as an argument an HTTP response object
responding to .ok
and returns a message string. Here’s an implementation, with an
early return, when response.ok
is truthy:
function flashMessage(response) {
if (response.ok) {
return 'It worked';
} else {
return 'It failed';
}
}
Same behavior, different code: omitting the else
and returning the second
string if response.ok
is falsy.
function flashMessage(response) {
if (response.ok) {
return 'It worked';
}
return 'It failed';
}
This is the common pattern that I think we can sometimes improve on.
Here’s the behavior, but without the early returns.
function flashMessage(response) {
let message;
if (response.ok) {
message = 'It worked';
} else {
message = 'It failed';
}
return message;
}
I chose a trivial example so I’d have to make a good argument1. I offer three:
Early returns…
Early returns build an opportunity for dead code into the function. Is
response.ok
ever falsy? It’s impossible to say with just this amount of
context. Maybe response
is an object like this:
const response = { ok: true };
Maybe our API is broken and it always returns ok
. In either case, everything
below that first early return is dead code.
I find early returns, especially many of them, hard to read.
With a single return we can say: “we create a variable, adjust it based on some conditions, and then return it.”
With multiple returns, it’s more like “check something, then maybe return, or check something else, then maybe return, or…”, etc. If a measure of readability is how simply the code can be translated into words, one return is superior.
My biggest issue with early returns is that they make debugging harder. If you want to know which conditional is evaluating with early returns, you have to stick a debugger or log statement into each one:
function flashMessage(response) {
if (response.ok) {
// Debugger or console.log here?
return 'It worked';
} else if(response.notFound) {
// ...and here?
return 'That record does not exist';
} else {
// ...and here? etc.
return 'It failed';
}
}
If the thing being returned is not a variable reference, such as
normalize(prepare(items.map(ToOption)))
you have to rewrite the code in order
to produce a useful log, while maintaining the return behavior.
With a single return, you can use one debugger or log statement and know it will always evaluate:
function flashMessage(response) {
let message;
if (response.ok) {
message = 'It worked';
} else if(response.notFound) {
message = 'That record does not exist';
} else {
message = 'It failed';
}
// A debugger or console log here is always evaluated!
debugger;
return message;
}
And it rarely stays this simple. You end up adding more conditionals, and the returns grow. When there are five conditionals, those early returns become tough to reason about.
function flashMessage(response) {
if (response.ok) {
return 'It worked';
} else if (response.unauthorized) {
return "You can't do that";
} else if (response.notFound) {
return 'That record does not exist';
} else if (response.unprocessable) {
return 'Could not update with the data you provided';
} else {
return 'It failed';
}
}
This is a gnarly function no matter how you write it. At least with a single return, we know the way “in” and “out” of the function.
This isn’t just an ergonomics argument. I can’t count the number of times I’ve been pairing on a bug, we aren’t using debuggers or log statements because of code like this, and we’ve been saying “it must be returning here” for an hour, only to find out that assumption is completely wrong. Code isn’t just for machines and humans, it’s for humans who are debugging, too.
Guard clauses are an exceptional case where I think early returns are nice. They say: “if this condition is true, exit!”
To revisit our example, perhaps we shouldn’t return a message if the response
doesn’t respond to ok
, because that indicates a bad response. Here’s a guard
clause with optional chaining.
function flashMessage(response) {
// If response doesn't respond to `ok`, return
if (response?.ok === undefined) return;
// ...rest of the function
}
I like guard clauses because they identify an exceptional state where the function should stop doing work.
My recent post Hash Fetch Instead of
If/Else offers one
example of an alternative to early returns. By using Ruby’s fetch
, we let a
language feature handle our conditional-style logic.
And it mutates the message
variable! We’re talking lesser of two evils. I think early returns are the greater evil.
What are your thoughts on early returns? Let me know!
Join 100+ engineers who subscribe for advice, commentary, and technical deep-dives into the world of software.