Feeds

Bloody code!

Multiple exit points

Business security measures using SSL

It's amazing how some good practices limp on for decades beyond their expiration date. I still encounter people who insist that a method should have only one point of return - as if we're all still littering our code with GOTOs, and the concept of a "black-box" function was never invented.

The way these same people go on about multiple exit points, you'd think they were headlining in one of the grislier episodes of ER trying to patch up the latest guest-star casualty while predicting dire consequences for the patient as they lie, bleeding to death.

People who prefer the single exit point tend to feel very strongly about it. But the reasons they give have never struck me as especially convincing. The following stream of generic reasons reminds me of the cookie-cutter platitudes that they roll out at the end of the more nauseating US TV series that seek to emulate ER, over the soul-grinding background warble of James Blunt:

  1. Bailing out early causes resource leaks. That's why we have the "finally" block. (If you're determined to have a single exit point, finally is the only way to achieve it. But purists take note, System.exit() still gets around it.)
  2. Multiple exit points make code harder to refactor. Yes, because simpler, clearer code is always harder to maintain.
  3. Multiple exit points is a return to GOTO and spaghetti code. Ironically, it's single-exit-point code that's the anachronism. The whole reason this misguided principle came about was the reaction to spaghetti code that was structured programming. In modern languages and runtimes, single-exit-point code is outmoded and can even be dangerous. For example, the ubiquity of exceptions means that no method is ever guaranteed to have a single exit point. Code as if it is, and you're asking to be caught out.
  4. Bailing out early creates an invisible "else" clause. What rubbish. A guard clause such as this:

if (account == null) return;

at the top of a method is much clearer, than:

if (account != null)
{ // 20 lines of code
// (that are totally irrelevant if account is null)
// later...
}
// and out we pop

Sometimes, trying to weave your code into a single return point results in setting of pointless flags and excessive nesting of "if..else" conditions. It's like wrapping a paper napkin around a seven-dimensional helix and trying to read the agile documentation off it. Figuring out whether each block of code is relevant to the current program state becomes a game of lining up the curly braces to figure out where each clause finishes.

It's easier to simply say: "Hey, I'm halfway through a method but I'm done. I'm outa here!" Artificially stretching the program flow to the end of the method just results in misleading code: implying that a block of code is relevant to a given state when the runtime really has no business still noodling around in there. If it's time to exit a method, exit the method already.

Adhering to an outdated maxim like "single exit point" results in a "one size fits all" approach to programming, which is hardly a good thing. But religiously hacking in multiple return points would of course be bad as well. If in doubt, go for the simpler, more expressive option which best communicates what the code means. It's more an article of faith than anything else. It's important to be able to take a step back and make a rational judgement call: this alone helps sort out the thinkers from the believers. ®

Agile Iconoclast Matt Stephens has co-authored Use Case Driven Object Modeling with UML: Theory and Practice, which explores ways to drive functional tests and unit tests from use cases.

Choosing a cloud hosting partner with confidence

More from The Register

next story
'Windows 9' LEAK: Microsoft's playing catchup with Linux
Multiple desktops and live tiles in restored Start button star in new vids
Not appy with your Chromebook? Well now it can run Android apps
Google offers beta of tricky OS-inside-OS tech
New 'Cosmos' browser surfs the net by TXT alone
No data plan? No WiFi? No worries ... except sluggish download speed
iOS 8 release: WebGL now runs everywhere. Hurrah for 3D graphics!
HTML 5's pretty neat ... when your browser supports it
Greater dev access to iOS 8 will put us AT RISK from HACKERS
Knocking holes in Apple's walled garden could backfire, says securo-chap
NHS grows a NoSQL backbone and rips out its Oracle Spine
Open source? In the government? Ha ha! What, wait ...?
Google extends app refund window to two hours
You now have 120 minutes to finish that game instead of 15
Intel: Hey, enterprises, drop everything and DO HADOOP
Big Data analytics projected to run on more servers than any other app
SUSE Linux owner Attachmate gobbled by Micro Focus for $2.3bn
Merger will lead to mainframe and COBOL powerhouse
prev story

Whitepapers

Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
WIN a very cool portable ZX Spectrum
Win a one-off portable Spectrum built by legendary hardware hacker Ben Heck
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.