Created
March 12, 2012 00:45
-
-
Save naush/2018923 to your computer and use it in GitHub Desktop.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # multiple exits | |
| if a | |
| code | |
| code | |
| code | |
| if b | |
| return c | |
| else | |
| return d | |
| end | |
| else | |
| return e | |
| end | |
| # single exit | |
| result = nil | |
| if a | |
| code | |
| code | |
| if b | |
| result = c | |
| else | |
| result = d | |
| end | |
| else | |
| result = e | |
| end | |
| return result |
Author
I mean we can refactor either approach to be reasonably easy to follow, but then you're just comparing two pieces of beautifully crafted code. :)
I'm just saying, when I'm trying to follow other people's code that looks like some longwinded maze, I prefer it to have a single exit point.
I'll accept that. Perhaps context is the differentiator here.
Author
Context definitely plays a big role here. I can see how early returns can help in some situations, too. Steven's rewrite is a good example.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
edit: this comment was in response to original gist.
I'd probably write it like this:
If c, b, and d were long, I'd write
And I suppose in reality, I'd probably extract some methods out of there (if not possible, then I might extract a class).