Is it ok to skip "return None"?

Question

I wonder if it is bad manner to skip return None, when it is not needed.

Example:

def foo1(x):
    if [some condition]:
        return Baz(x)
    else:
        return None

def foo2(x):
    if [some condition]:
        return Baz(x)

bar1 = foo1(x)
bar2 = foo2(x)

In both cases, when condition is false, function will return with None.

Solution 1

Like you said, return None is (almost) never needed.

But you should consider that the intention of your code is much clearer with an explicit return None. Remember: a piece of code also needs to be readable by human-beings, and being explicit usually helps.

Solution 2

To expound on what others have said, I use a return None if the function is supposed to return a value. In Python, all functions return a value, but often we write functions that only ever return None, because their return value is ignored. In some languages, these would be called procedures.

So if a function is supposed to return a value, then I make sure all code paths have a return, and that the return has a value, even if it is None.

If a function "doesn't" return a value, that is, if it is never called by someone using its return value, then it's ok to end without a return, and if I need to return early, I use the bare form, return.

Solution 3

Yes and No.

In the simplest case, it is ok to skip "return None" because it returns None in only single negative condition.

But if there are nested condition evaluation and multiple scenarios where a function could return None. I tend to include them as visual documentation of the scenarios.

[Editing: Based on comment below]

return or return None

I prefer "return None" to bare "return" as It is explicit and later, no one will be in doubt if the return meant returning None or was it an error as something was missing.

Solution 4

Yes, if you do not return any value from a Python function, it returns None. So, whether to explicitly return None is a stylistic decision.

Personally, I prefer to always return a value for clarity.

Solution 5

The more I think about it, the less I think the case you describe shows good practice. It forces the client to discriminate, so client code would almost always look like:

b = foo1(123)
if b is not None:
    ...

You couldn't even write:

if b:
    ...

since, if Baz.__nonzero__ is overwritten, b could evaluate to False, even if it's not None. It would be better to have a Null-Baz instance (AKA Null Object), e.g.:

class Baz(object):
    def some_method(self):
        """some action:"""
        ...
    ...

class BazNull(Baz):
    def some_method(self):
        """nothing happens here"""
    ...

Baz.Null = BazNull()

...

def foo1(x):
    if some_condition:
        return Baz(x)
    else:
        return Baz.Null

...

b = foo1(123)
b.some_method()

The point is: help the client (who might be yourself!) to keep Cyclomatic Complexity low. The fewer branches, the better.

View more solutions

Comments

[pabouk - Ukraine stay strong]

Note: I think that in the foo1() definition it is much cleaner to remove the else: branch and put return None at the end of the function.

[Nick T]

Also helps to "comply" with import this :P

[adw]

Even with nesting you could just use return instead of return None. Sometimes it can be clearer to make the None explicit, but often people use None to indicate some sort of exceptional case, in which case raising a well-named exception would be better.

[dln385]

What about at the end of an __init__ method? Since you can't return None, is it better to have return or nothing at all?

[adw]

@dln385: You can return None in __init__, in fact that's what return does.

[rsenna]

@dln385: I don't know if __init__ is a proper constructor in Python, but it certainly works as one. So it should not return anything.

[pyfunc]

@adw : I agree with you. Some of these are style habits. I abhor using just "return" as if I had missed returning something. I prefer "return None" in such cases as I am explicit that this is what I wanted.

[dln385]

Sorry, I must have been thinking about another language like Java. In Python, you can indeed return None in __init__. In fact, if you try to return a value, it says TypeError: __init__() should return None

[Tony Veijalainen]

I personally do not use None for exceptional value but usually use it as place holder to indicate place for value. [] or () then indicate indefinite number of results and for some kind of functions they are better False-like value than return None (as None is not iterable)

[Davy8]

"Explicit is better than implicit."

[Davy8]

and @Nick I just got it, +1 to your comment :p

[Glenn Maynard]

People parroting the "Zen of Python" make me constantly with for comment downvotes. Implicit is better than explicit when it's clearer and avoids needless redundancy.

[Glenn Maynard]

@dln385: Don't return None unless the None return value itself is meaningful. The return value of __init__ is not meaningful, so don't explicitly return None. If you need to return from the middle of __init__ just say return, and don't put an unnecessary return at the end of the function.

[rsenna]

@Glenn Maynard: so there's no need to be explicit, because there is no intention to return anything. I rest my case... :)

[Tomasz Wysocki]

Good point. But in some cases I'm forced to return None. Ie. in Django Middleware you will return None in most of your methods.

[madhukar93]

A foolish consistency is the hobgoblin of little minds. No need to increase the noise in your code just to be explicit, when anyone who knows anything about python can tell what would happens even when you don't add that return.

[rsenna]

@EagerNoob I'm not saying to "consistently" add return None to every method - I'm just saying the intention of OP's specific code is made clearer by adding return None. Also, world is full of little minds, and I try to write code they could read as well.

[madhukar93]

@rsenna I pretty much agree with with you :), sorry if I wasn't clear ! I was disagreeing with people who were citing "explicit is better than implicit" here. return None might make sense where a function always returns a value, but for certain code paths no value is available. Here it would be more readable to be consistent with each code path ending with a return statement. Although just return seems sufficient and return None seems like overkill as Glenn pointed out.

[ehabkost]

I downvoted this because even if the suggestion is valid in some cases, it is outside the scope of the question.

[Matthias Fripp]

I would go further than this. I wish that Python functions returned a "No Value Returned" object by default, instead of None, and that Python raised an error if you ever tried to use the "No Value Returned" object (print it, assign to a variable, etc.). That would catch fairly common mistakes where people omit the return from a function. Then Python could also be changed to show None on the command line if you call a function that really does return None or remain silent if the function doesn't return anything. I got here by checking if there was a pep for this already, but no luck!