Comments on: Multiple Returns from a Single Method http://agilepainrelief.com/notesfromatooluser/2008/08/multiple-returns-from-a-single-method.html Best practices for your goals Sat, 13 Mar 2010 23:35:46 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Dave Rooney http://agilepainrelief.com/notesfromatooluser/2008/08/multiple-returns-from-a-single-method.html/comment-page-1#comment-152 Dave Rooney Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/08/multiple-returns-from-a-single-method/#comment-152 It's funny - once upon a time I was a die-hard advocate of "one entry point, one exit point" for a method or function. My main argument for this was that it greatly simplified debugging. Then, I found out about automated testing in general and TDD in particular and I've switched camps to be an advocate of "early returns"! I would say, though, that early returns don't necessarily make code less complex. If the code isn't well-factored to begin with, they can actually make the code less readable. I think that maybe a better way to put this is that if the code has good automated tests and is well-factored (according to Beck's priority list), then early returns can make it even more readable than nested control structures. There's a synergy there that needs to be brought to the surface. Dave... It’s funny – once upon a time I was a die-hard advocate of “one entry point, one exit point” for a method or function. My main argument for this was that it greatly simplified debugging. Then, I found out about automated testing in general and TDD in particular and I’ve switched camps to be an advocate of “early returns”!

I would say, though, that early returns don’t necessarily make code less complex. If the code isn’t well-factored to begin with, they can actually make the code less readable. I think that maybe a better way to put this is that if the code has good automated tests and is well-factored (according to Beck’s priority list), then early returns can make it even more readable than nested control structures. There’s a synergy there that needs to be brought to the surface.

Dave…

]]> By: BlogReader http://agilepainrelief.com/notesfromatooluser/2008/08/multiple-returns-from-a-single-method.html/comment-page-1#comment-153 BlogReader Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/08/multiple-returns-from-a-single-method/#comment-153 I like multiple return statements not just for cutting down on if..then indentation but to show the reader where the meaty problems like. That is, I exit early in simple cases to show the reader that these problems were easily taken care of. If you continue on in the method means something harder had to be done. I like multiple return statements not just for cutting down on if..then indentation but to show the reader where the meaty problems like. That is, I exit early in simple cases to show the reader that these problems were easily taken care of. If you continue on in the method means something harder had to be done.

]]> By: xcd esz http://agilepainrelief.com/notesfromatooluser/2008/08/multiple-returns-from-a-single-method.html/comment-page-1#comment-154 xcd esz Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/08/multiple-returns-from-a-single-method/#comment-154 Some of your points could be reversed. You say "If more code is added later it might accidentally get run even though its author intended the method to be finished." The reverse is more likely to be true. If a developer goes back to the method and wants to do something with the result set before returning, now he has to find all of the return points. Having multiple return statements may be easier for you to write, and less "lines of code". But as someone who has to maintain others code, I often find myself having to wind my way out of a spaghetti of loose practices such as this. Yes, if your code only has a few lines, having mutiple returns wont be a problem. But where do you draw the line? It is better, IMHO, to stick with the old rule. Some of your points could be reversed. You say “If more code is added later it might accidentally get run even though its author intended the method to be finished.” The reverse is more likely to be true. If a developer goes back to the method and wants to do something with the result set before returning, now he has to find all of the return points.

Having multiple return statements may be easier for you to write, and less “lines of code”. But as someone who has to maintain others code, I often find myself having to wind my way out of a spaghetti of loose practices such as this. Yes, if your code only has a few lines, having mutiple returns wont be a problem. But where do you draw the line? It is better, IMHO, to stick with the old rule.

]]> By: William Pietri http://agilepainrelief.com/notesfromatooluser/2008/08/multiple-returns-from-a-single-method.html/comment-page-1#comment-155 William Pietri Tue, 30 Nov 1999 00:00:00 +0000 http://agilepainrelief.com/2008/08/multiple-returns-from-a-single-method/#comment-155 I agree with Dave. In well-factored code, early returns are fabulous. I use them all the time to dispose of contract violations and degenerate cases, so that the method code can focus on the interesting part of the problem. They can also be nice when expressing a simple set of rules. E.g., in a Java equals method, I often find it much more readable to express it as a series of "if ... return" lines rather than one giant boolean expression. And I'm sure they have other uses as well. In ugly code, I do think they can make things mildly uglier. But I think the solution there is refactoring for clarity, not adding rules to try to make mud slightly less dirty. I agree with Dave.

In well-factored code, early returns are fabulous. I use them all the time to dispose of contract violations and degenerate cases, so that the method code can focus on the interesting part of the problem.

They can also be nice when expressing a simple set of rules. E.g., in a Java equals method, I often find it much more readable to express it as a series of “if … return” lines rather than one giant boolean expression. And I’m sure they have other uses as well.

In ugly code, I do think they can make things mildly uglier. But I think the solution there is refactoring for clarity, not adding rules to try to make mud slightly less dirty.

]]>