2

I'm trying to sort out whether this is just a personal preference thing or whether it's actually bad practice to do this one way or another. I did try to reference PEP8 first, and I did not see an answer.

What I'm talking about here is the use of more than one return statement. In these examples, it's not such a big deal, as they are very short and easily read.

def foo(obj):
    if obj.condition:
        return True
    return False

def bar(obj):
    answer = False
    if obj.condition:
        answer = True
    return answer

It bugs me to assign a variable every time bar() is called, instead of just determining the answer and returning it. But in a longer function a second return might be hidden and so someone reading the code may have not realized that the function might return a value before hitting the end of the line:

def spam(obj):
    blurb = "Francis"
    if obj.condition:
        blurb = map(gormf, [z for z in porp(obj)])
        return blurb[2]
    elif not obj.condition and dreg(obj.jek):
        blurb = obj.hats * 17
        if blurb % 13: return blurb
    else:
        blurb = obj.name
    return "Whales and %s" blurb

That's a terrible function, but I think you see what I'm poking at.

So is it preferable to create a function to have a single, clear exit - even if it's a few more operations than you actually need? Or should one try to root this out whenever possible in favor of shorter code?

  • 2
    Respectfully, I don't think this is a duplicate of that question; (a) Python is very NOT Java (b) languages have their preferred methods of doing things, so even if there were a good answer that applied to Java's best practices, it might not apply to Python's at all (c) the subject matter in the question with no apparent accepted answer ranges all over the place; SESE is a whole other ball of wax that I don't think even applies to anything written in pure Python. So I appreciate the link, but I think I disagree with the duplicate status. –  Mar 23 '14 at 23:12
  • http://meta.stackexchange.com/questions/194476/someone-flagged-my-question-as-already-answered-but-its-not – gnat Mar 24 '14 at 12:10

2 Answers2

3

My personal preference is to allow multiple returns at the very beginning and the very end, but not in the middle (where they could be easily missed).

Of course, one might argue that if a subroutine is so long that it has a "beginning", "middle" and "end", it is too long anyway.

I am specifically fond of using the trailing Perl-style conditionals as sort-of "guard expressions" (example in pseudo-Ruby, but applies equally to other languages):

def sort(list)
  return []         if list.empty?
  return list.clone if list.size == 1
  ... actual sorting here
end

Or in Python:

def sort(list):
  if not list:       return []
  if list.size == 1: return list.clone
  ... actual sorting here
end
Jörg W Mittag
  • 101,921
  • 24
  • 218
  • 318
  • I really like this idea. I'm not a syntax stickler, necessarily, so while I am curious as to the preferred Pythonic way of dealing with this, I also like this 'guard expression' idea as well. –  Mar 24 '14 at 13:31
0

Setting aside the fact that "if true then true else false" is silly, one thing to keep in mind is that foo() only has two returns because if is a statement in Python, not an expression. In a functional language like Standard ML, where everything is an expression that returns a value, foo() would look like this:

fun foo (obj) =
    if obj.condition
    then True
    else False

So, conceptually, your foo() could be considered to have a single return.

Multiple returns starts to get confusing is when you combine them with side effects and looping statements. In that case in can get tricky to follow the execution of the function and determine whether it'll abort early or not. But once that's an issue, rewriting the function to be easier to follow and understand is far more important than adhering strictly to some style guide or another.

Doval
  • 15,347
  • 3
  • 43
  • 58
  • I realize my examples were sophomoric, but I was asking more about the nature of the syntax than whether or not the actual functions in question were of any merit. I assumed that this was one of those "one right way to do it" things which PEP8 or other reading material would outline. –  Mar 23 '14 at 22:45