When writing, be careful of presenting an opposing point first with the notion that you’ll make your counterpoint in a subsequent paragraph or page. That first pitch is often as far as some readers get. Royce’s article “Managing the Development of Large Software Systems” led to decades of waterfall for this reason.

Recently, a pair-developer expressed concern over the use of multiple returns in a short method. I said I knew about the long-standing rule but that it created little value for very short methods. Two days later, I heard the same concern during another pairing session. Twice in one week? Curious!

I asked where they’d read about the rule. “Uncle Bob’s Clean Code” was the surprising response. “Hand me your copy!” I insisted, a bit worried, and quickly located the text in the functions chapter. The very last paragraph on page 48, starting a new section, states: “Dijkstra rules of structured programming… [say] …every function … should have one entry and one exit. Following these rules means that there should only be one return statement in a function…” Oh! Yeah, I learned that 30 years ago. Really, Bob?

Page 49, top paragraph: “”While we are sympathetic to the goals and disciplines of structured programming, these rules serve little benefit when functions are very small. It is only in larger functions that such rules provide significant benefits.”

Oh, ok. Whew! Crisis of faith averted.

Readers: Inattentive reading can be embarrassing!
Writers: Don’t assume readers will get to your point. Make it first.

Comments

Tim Ottinger October 26, 2011 at 7:34 am

Oh, good point. I’ve a tendency to try to connect first with a shared idea and then to follow on with my refutation. I’ll try not to do that in the future. Good observation, Jeff.

Rudi January 27, 2012 at 5:40 am

Ah, I had the same annoying feeling while reading that page. But surely Bob, code is much cleaner if you Fail Fast and Exit Early. One Exit point is just not clean, you tend to get indentation. And less readable code.

Example:

public void SomeMethod(SomeType parameter)
{
  if (parameter != null)
  {
    if (parameter.Member == someValidValue)
    {
      // do something here.
    }
  }
  else
  {
    throw new ArgumentNullException();
  }
}

public void SomeMethod(SomeType parameter)
{
  if (parameter == null) throw new ArgumentNullException();
  if (parameter.Member != someValidValue) return;`

    // do something here.  
}

Which one would read best?

Jeff Grigg March 2, 2013 at 1:03 am

Right; structured programming rules were made for BIG functions. It predates modular programming rules, so you should assume >>>BIG<<< functions — possibly thousands of lines long!

With short, well-focused methods, if the point of the method is to loop through things and return the right one — then it’s best to do just that: One return in the loop for when you find it, and one return at the end for when you don’t find it. Likewise, methods that are primarily a switch-case to decide the right thing to (do and) return, it makes sense to have a whole list of return statements in the method (and little else!!!).

Issue: “But what if we need to add doing “X” before exiting the function?!?”
Answer: Learn how to make one function call another.
In other words, “Extract Method” on the part with two returns, Extract Local Variable on the part that is now just a return statement, and then insert “doing X” between those two lines. It’s OK to have more methods/functions/classes. They don’t cost much. And they are our tools for organizing code.

Issue: “But multiple ‘return’ statements interferes with refactoring tools!”
Answer: Get better tools. And, short term, learn to do refactoring yourself; don’t be limited by your tools. There will always be things that the tools can’t do for you. Empower yourself.

Share your comment