Well written article and an enjoyable read. Only part I disagree with is your stance on “early exit”, it turns out that this is the tiny hill i’m willing to die on, one I was unaware I cared about until now. I think this is primarily because if I read code that has a return within an if block then anything after that block is inferred else.

I could become pedantic and retort that all control flow is a goto at the end of the day but I wont, because that would be silly and this was a genuinely good read, thank you for sharing.

In rule 2 he refactors this:

if (a and not b) {
      do this
  } else if (a) {
      do that
  } 

  if (b) {
      do the other thing
  }

To this:

  if (a) {
      if (not b) {
          do this
      } else {
          do that
          do the other thing
      }
  } else {
      do the other thing
  } 

And I stop reading…

If you have such logic then types and case analysis (i.e. pattern matching) is much clearer and easier to reason about. The fact that he makes a mistake just underlines this point. if is a very implicit way to state your assumptions.

I appreciate people who handle all possible inputs and I think that is a case where early return is somewhat idiomatic, i.e. something like:

(progn
  (when (!preconditions) (return error))
  (...logic))

I can’t agree with the “early exit” argument. Additionally, the “solution” presented after the ‘early exit via throw’ example, adds a problem: you now essentially have two versions of the same function, one that has error handling, and one that doesn’t.

I will bet you real money, the variant without error handling will get called from somewhere else by someone in the future.

Furthermore, this argument is just factually wrong:

We all know that if statements should handle all possible cases

No. A single if statement should handle a single possible case.

Even an if + elseif series of statements don’t necessarily handle every possible case.

This is perfectly exemplified in one of the author’s earlier “real world” references:

“Bring me a coffee if you get home early.”

Is the author really suggesting that what’s meant here is “Bring me a coffee if you get home, otherwise don’t bring me a coffee”. Sometimes there is nothing else to do, if the condition isn’t met.

Not every conditional execution has a negated action required. This is evidenced by the need for a very specific example to prove the “need” for an else.

Incredible to see such an opinionated (and flawed) article with that many upvotes.

This approach doesn’t works every single time and it just gives more ammunition to those annoying people who don’t understand that.

You’ve got a few mistakes in your example code (the conversion of assembly to structured, the a and not b example, and I think at least one more). Because your argument is so focused on correctness and readability, I think the errors undermine your argument.

A lot of these examples work well when the code fits in ~20 lines. In almost all code I write for work, functions are 100s of lines easily, for ~reasons~. They start with error handling and bounds checks - which this article doesn’t address.

Once you’re up to 100’s of lines, I would get very pissed off if a coworker did not use early returns to rule out boring edge cases in the main function. The example sentence:

If you don’t get home early ignore everything I’d say after this sentence. Bring me a coffee.

Which seems weird, but instead if it was:

If don’t use our service, you should go back and read the front page! Anyways, <insert entire description of ToS>.

Rule 1 - DO NOT use return for control-flow

Stopped reading here. Anyone who believes in saying words like “early exit” is not an influence I need in my life.

Some of the examples provided in the text look like watered-down versions of real use cases which happen to benefit from the proposed refactorings. But, for instance, if one has to check more than one error condition, that will lead to either a bunch of cascading ifs or an unreasonable number of auxiliary functions. At that point, the readability benefits of keeping separate branches of the same if clause vanish quickly.

Forgive me if I am wrong here, but my understanding of Dijkstra’s essay was that goto should not be used in situations where a function call could be used instead. The reason he gives is that it undermines the usefulness of the stack trace as function calls are traceable and gotos are not. This would not really apply to if statements. If statements do not influence the stack directly and therefore are not really any different from gotos where the stack is concerned.

This also applies to the seemingly most controversial part of the article, early exit. A function that completes is not traceable regardless of where or when it returns, once it returns it is popped off the stack and there is no record of whether it exited early or not.

I also wondered why the nested if was not refactored to:

if (b) {
  do the other thing
  if(a) {
    do that
  }
}
else if (a) {
  do this
}

How is a function called signup_internal or _signup better than a early return right at the top? If you can’t give something a meaningful name, better avoid naming it!

If this was focused more on types, you’d see how the error type is part of a “presentation layer” and probably uses a presentation-layer monad that the business logic shouldn’t need to care about ;)

I like most of this except the rule against early returns. Consider the suggested alternative:

if (input less than waterleve) {
    turn motor on
} else {
    turn motor off
}

When reading this code, you ask yourself “when can the motor be turned off”? To answer that, you need to reason about the control flow that can enable that statement to be reached. You have to look up at the if condition. When that condition is true, the then block is run. Then you negate the condition in your head and understand that the else can only be reached when the condition is false. That’s exactly the same mental processing you do for an early return.

In particular, consider a more complex example using early returns:

if (file does not exist) return file not found error;

if (file is empty) return file empty error;

if (file cannot be read) return read error;

read file;

The author argues that this is better written as:

if (file does not exist) {
  return file not found error
} else if (file is empty) {
  return file empty error
} else if (file cannot be read) {
  return read error;
} else {
  read file;
}

But, again, ask yourself, “When does the file get read?” The answer to that is “When the file exists, and it’s not empty, and it can be read.” Even though there are technically no “early returns”, the chain of else if clauses still means that you have to maintain all of those if conditions in your head when reasoning about the control flow. The underlying control flow is the same, as is the cognitive load.

Also, for what it’s worth, I think Dijstra’s “Goto Considered Harmful” letter to be a weak, poorly-argued claim and Dijkstra’s own “guarded control flow” language is just as bad as goto according to his own logic.

I think weaker versions of rules 1 and 3 are helpful under limited circumstances.

I slightly like a much weaker version of the “no early returns” rule (1). I often prefer to have no early returns in a subroutine after the first point where it does something that has an externally visible effect. Before that point everything will be read only. (I guess this implies that in pure functional code, keeping flow control simple is less important.)

The “always do something in else” rule (3) makes sense in event handlers for things like form submits or button clicks, when refraining from going ahead with the thing the user asked for because something was not available. I certainly do not want to log every branch anywhere that was not taken: the log output will be too spammy to read.

The “do not encode date in if statements” rule (4) is bad. The “before” code is simpler and easier to read than the “after” code. The mini interpreter that had to be written to make use of the data table is more complicated & more likely to be buggy than the code it replaced. By all means put the amounts and bands in config, but otherwise that stuff is business rules, not data.

we already have a mechanism to edit the rules without code changes

This embodies soft coding. You can end up with a system where supposedly ordinary users can configure the system’s behaviour, but the configuration is code (for a weird machine with terrible debugging and IDE support) so ordinary users fear it, refuse to touch it and demand that programmers be the ones who update the configuration. At that point you might as well have written that code in a programming language which has nice tooling.

The bit under “Data-driven error handling” is good, polite behaviour for user interfaces. Reporting errors one at a time in UIs is rude. I would not call it strongly desirable in APIs though. I’d rather have APIs with simple, less-likely-to-be-buggy code behind them then APIs that try to be extra polite about error handling and risk bugs by making it complicated.

This feels very 1970s. I’m expecting the ghost of Fred Brooks to pop up and scowl at me.

(This is likely an urban legend but I could swear I saw it accused somewhere that the real reason for “no early exits” was because some people were writing programs up as flow charts prior to entering them into the computer — punch cards cost money! — and their flow chart notation was missing a notation for early returns. Another more plausible supposed reason is that prehistoric variations of Hoare logic didn’t accommodate them in proofs, despite the fact that simple mechanical translations to other control flow forms exist.)

Thanks for this article. Even if I’m not sure I agree on these things, I like these articles because they try to address what is good programming, and it feels like there are not a lot of them. Currently there is a lot more talk about cool programming languages. I also enjoy those, however I’m starting to think that learning a lot of programming languages doesn’t necessarily turn you into a skilled programmer. It may expose you to new ideas but it doesn’t necessarily teach you anything. A bit like copying math formulas doesn’t necessarily teach you math.

I couldn’t upvote this more (besides that I literally can’t). Also, this article has made finally understand the Elixir design decision of not having a return statement.

In typescript, an early return of an object literal lets it be typechecked properly, while a variable returning doesn’t seem to have the same effect. Might be related to specific versions.

Short history of the if statement? Was McCarthy exagerating when he claimed to invent it in 1960?

https://en.wikipedia.org/wiki/McCarthy_Formalism#McCarthy's_notion_of_conditional_expression