Python-list Digest, Vol 169, Issue 23

[ROGER GRAYDON CHRISTMAN]

The opinions I give in this post are not as strong as
the opinions I expressed before about the loop claiming
to count all the way to 2**64.   But I'll give them anyway.

I don't mind having return's inside an if statement, when
the function ends with that if statement.   It becomes very clear
then that there is a choice of possible results, and that exactly
one of those choices apply.

def foo():
... if condition:
...... return 1
... else
...... return 2

I would expect this to be the same as the "# with multiple exits"
with a possibly very minor increase in clarity.

I have used several IDE's that let you mask out chunks of code
based on their indentation level.   Sometimes I use that concept
as an estimate of readability (minimizing how much a reader 
has to look at to understand the structure of the code.
Contrast my multiple-exit with the one I quoted:

def foo():                             def foo():
    if (condition)                         if (condition0
        [...]                                        [...]
    else:                                     return 2
        [...]

If someone was only reading lines indented once, and skimming the rest as
details unimportant to the structure, he might have a misleading assumption 
about the return value in the code on the right.    On the left, he would look
be forced to look one level deeper to find the return's, and find two outcomes.

This same level-of-indentation measure also argues against break and continue,
since statements would also be further indented, which might make them easier
to miss.

But, in any case, I do not mind multiple return's clearly marked with if/else.

On the other hand, I still recommend against return statements inside of loops.
It shouldn't be hard to find the appropriate way to leave the loop, and return
afterwards.   My position is also in line with one of my hard and fast rules for
early programming students:

Rule:  If the operation does not repeat, do not put it into a loop.

I don't even make an exception for return statements.   And my justification
for not making an exception is not only to simply the pedagogy
(absolutism is much easier to explain), but also goes along with the
other maxim:

The code should be obvious!

There are just so many times when I see students expect a return
statement within a loop to be able to return more than one value.
It happens both when reading code, and when writing code,
and even happens for upperclassmen, who should know better.
Clearly, if such a misinterpretation is prevalent, the code is not obvious.

And that's even ignoring the benefit of being able to
set a breakpoint at the very bottom of a function when debugging.

Roger Christman
Pennsylvania State University


On Thu, Oct 12, 2017 12:26 AM, Steve D'Aprano wrote:
>

>
>Message: 3
>Date: Thu, 12 Oct 2017 12:26:07 +1100
>From: Steve D'Aprano <steve+python at pearwood.info>
>To: python-list at python.org
>Subject: Re: Looping [was Re: Python and the need for speed]
>Message-ID: <59dec4b0$0$14935$b1db1813$d948b532 at news.astraweb.com>
>Content-Type: text/plain; charset=utf-8
>
>
>But from the point of view of the subroutines, the rule "one exit" is
>like the
>rule "no break" for loops: it makes the code more complex and less
>efficient.
>If you're done, you're done, and you might as well return out of the function
>rather than write boilerplate code to pad it out until you get to the very
>end. With only a single condition to test, there's not much difference
>between the two:
>
># with single exit                      # with multiple exits
>def foo():                              def foo():
>    if condition:                           if condition:
>        result = 1                              return 1
>    else:                                   return 2
>        result = 2
>    return result
>
>
>but as the number of decision points increase, the complexity required to keep
>a single exit also increases.
>  
>
>