A few months ago, a reader emailed me for my views on single versus multiple return statements in a method…

Nobody expects the Spanish Inquisition"What’s your take on single-vs-multiple returns in a method?

Personally, I don’t mind multiple returns. It often makes code more readable, less if-nesting, etc. But it has almost become a war here at my workplace, with a few people saying it’s "bad programming" to have more than one exit from a method."

And I thought – wow, are people really still fighting over this? But then, I’m reviewing some code with an otherwise totally competent coworker the other day and he mentions how much he dislikes methods with multiple returns. Huh!

So, I thought I’d post my response and see what others think.

"I believe if you have a function that, in certain scenarios, completes all of it’s required processing before it’s reached the end of the function block, then by failing to return at that point, you’re:

a) risking the chance that additional processing will incorrectly occur, and
b) forced to add if/else nesting to ensure your function’s additional processing does not occur for this scenario.

As you eluded to, the additional nesting of if/else blocks makes the code harder to read and more difficult to maintain, thus increasing the likelihood of errors and the amount of effort to maintain it.

But the worst part is that if you’re setting a value and you choose – even after setting the appropriate value for this scenario – to keep processing, you risk inadvertently changing the value from the right one to an incorrect one. Honestly, this is how I was taught to code (always prefer a return an else{}), so I’ve never really understood the justification to continue processing after you’re – well – done!"

It’s like continuing to loop through a list after you’ve already found the value you were looking for. What’s the point?

Bob Martin also addresses this in Clean Code, stating that while it was good practice at one point, that doesn’t mean we should just blindly enforce the rules of structured program in today’s object oriented world:

"Some programmers follow Edsger Dijkstra‘s rules of structured programming. Dijkstra said that every function, and every block within a function, should have one entry and one exit. Following these rules means there should only be one return statement in a function, no break or continue statements in a loop…

While we are sympathetic to the goals and disciplines of structured programming, those rules serve little benefit when functions are very small. It is only in larger functions that such rules provide significant benefit. So, if you keep your functions small, then the occasional multiple return, break, or continue statement does no harm and can sometimes even be more expressive then the single-entry, single-exit rule."

What do YOU think about multiple returns? Good programming practice or devil spawn?

Do you want to push the edge on what's possible?

Abby Fichtner works with some of the world's top organizations and universities to incite creativity and spur extraordinary results.

Whether you're looking to foster innovation, create a 21st Century workplace of engaged employees, or become a change leader in your industry -- bringing in an expert who's helped hundreds of companies do the same is a brilliant way to accelerate your results. Bringing excitement and fresh perspectives to rally your entire organization in your growth and success.

Contact Abby today and let's talk about how we can make you a hero in your organization's success.