Jake Worth

• javascript

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.

Common Code: Early Returns

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.

My Preference: One Way Out of a Function

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 argument¹. I offer three:

Early returns…

• Build dead code into the function
• Are harder to read
• Are harder to debug

Dead Code Built In

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.

Harder to Read

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.

Harder to Debug

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.

Counterargument! Guard Clauses

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.

Alternatives

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.

What are your thoughts on early returns? Let me know!