"return" in def

[Bruno Desthuilliers]

Steven D'Aprano a écrit :
(snip)
> Avoiding early exits is an over-reaction to the Bad Old Days of spaghetti 
> code. 

Mostly, yes. It can also be a way to help avoiding "resource leaks" 
(memory or whatever) - just like try/finally blocks or the 'with' 
statement in Python.

> But used wisely, early exists can simplify, not complicate, code.
> 
> Consider the following:
> 
> def find_ham(alist):
>     for item in alist:
>         if isinstance(item, Ham):
>             return item
>     raise ValueError('no ham found')
> 
> 
> def find_spam(alist):
>     found_item = None
>     for item in alist:
>         if found_item is not None:
>             if isinstance(item, Spam):
>                 found_item = item
>     if found_item is None:
>         raise ValueError('no spam found')
>     else:
>         return found_item
> 

> The second version has double the number of lines of code of the first. 

And doesn't do the same thing (hint: you forgot a break statement). Also 
and FWIW, the "single exit" golden rule (hem) comes from languages 
without exception handling. So a fair comparison would be:

def find_egg(alist):
    for item in alist:
        if isinstance(item, Egg):
            return item
    return None

vs:

def find_sausage(alist):
    found = None
    for item in alist:
        if isinstance(item, Sausage):
            found = item
            break
    return found

Granted, this still doesn't make the second version better than the 
first !-)

But:

> I  don't think the claim that the version with an early exit is more 
> complicated than the version without can justified.

Certainly not in this simple (simplistic ?) example. Now in C or Pascal, 
functions tend to be much longer and complicated, thanks to all the gory 
details one has to take care of.

Not that I'm advocating "no early return" as a "golden rule" - specially 
in Python where functions tend to be short and readable -, but there 
really are cases (depending on the language *and* concrete use case) 
where avoiding early returns makes for more readable and robust code.

My 2 cents...