Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discourage multiple exit points in a method (multiple return) #15

Open
daodennis-zz opened this issue Jan 4, 2016 · 7 comments
Open

Comments

@daodennis-zz
Copy link

It can be confusing to have multiple exit points in a method.

With blessings of the powers that be I would like to submit an example (asking for guidance on where) to recommend using only one exit point in a method instead of multiple so it is easier to follow, i.e. only one return statement. Thoughts?

@amontalenti
Copy link
Owner

@daodennis This is a great suggestion -- thanks for participating here!

I would be glad to look over an example. I sometimes struggle myself with whether multiple return statements aid, or hurt, readability of a function. I know one form that many people are fond of is the "default return", e.g.

if some_condition:
    return special_calculation()
return default

and it's hard to argue with the readability of that. But I tend to agree that several exit points to a function (especially a deeply nested function) can be quite confusing.

@blagh
Copy link

blagh commented Jan 5, 2016

I would argue that this is like the short variable naming advice - if the exit points are easy to see and close together, it is still easy to parse and to understand what is going on. It certainly helps keep indentation down, where in more complicated cases this could lead to multiple nested if statements.

@daodennis-zz
Copy link
Author

Thanks @blagh I will add that sentiment.

@ulope
Copy link

ulope commented Jan 5, 2016

I would argue that there is nothing wrong with multiple returns per se but rather that if your function or method has become so huge that you can't look from one return to the next you have way bigger problems in your code base.

@blagh
Copy link

blagh commented Jan 6, 2016

It occurs to me I would also encourage having the "happy path" be the final
return statement (and hence, the last statement), and all others be error
cases.

But that could just be personal preference.
On Jan 5, 2016 18:51, "Ulrich Petri" notifications@github.com wrote:

I would argue that there is nothing wrong with multiple returns per se but
rather that if your function or method has become so huge that you can't
look from one return to the next you have way bigger problems in your code
base.


Reply to this email directly or view it on GitHub
#15 (comment)
.

@amontalenti
Copy link
Owner

Someone recently shared "The Hitchiker's Guide to Python" with me, and it includes a section on this topic in its style guide:

http://docs.python-guide.org/en/latest/writing/style/#returning-values

@rsmith-nl
Copy link

It makes sense to have only one return statement in functions that have to do clean-up before returning in case of an error.

Examples of such clean-up would be e.g. closing files and sockets or (in C) free-ing memory. Using the with-statement precludes the need to close files manually. And in Python3 the same goes for sockets. Manual memory management is simply not an issue with Python.

So in general, I don't think it is necessary to restrict yourself to one return.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants