[Tutor] Multiple exits in a function...

[Jeff Shannon]

I find this conversation interesting.  Some very respectable 
programmers on comp.lang.python espouse the very thing that Alan is 
recommending against, so this isn't necessarily a clear-cut issue.  I 
do agree with Alan's points, but there's complicating factors too.

Alan Gauld wrote:

> For example:
> 
> test = obj.read()
> while test < 100 and not eof(foo):
>      block here

However, if you expand this just a bit to show the loop 
re-initialization, it doesn't look quite so clean --

test = obj.read()
while test < 100 and not eof(foo):
     [block here]
     test = obj.read()

You have to set test in two different places, one of which is at the 
*end* of the loop.  This is counterintuitive and confusing in a 
different way.  And you've got the maintenance hassle of duplicated code.

> vv
> 
> while not eof(foo):
>      test = obj.read()
>      if test: break
>      block here

I (and, I believe, the c.l.p gurus who espouse this loop structure) 
would prefer to write this differently:

while 1:
     test = obj.read()
     if test >= 100 or eof(foo):
         break
     [block here]

By explicitly making this an infinite loop, it sends a clear signal to 
the reader that one must look elsewhere to find the loop exit.  It's 
true that the terminating condition is now hidden within the loop, 
which is unfortunate, but at least all possible terminating conditions 
are in the same place.  In fact, there *is* a single exit to this 
loop, as suggested by structured programming; it's just that the exit 
is within the body of the loop, rather than right at the top.

In fact, one could summarize the loop structure like this:

while 1:
     [iteration initialization]
     if [terminating condition(s)]:
         break
     [loop body]

To my mind, as long as this structure is closely followed, then one is 
staying fairly close to the spirit of structured programming, if not 
the letter.  One can look at this as a spelling variation of a 
do...while...repeat loop -- AFAIK (which admittedly isn't terribly 
reliable), that structure isn't specifically deprecated in structured 
programming.  And, at least to my mind, it seems cleaner than the 
structure Alan is recommending, which would be similarly summarized:

[iteration initialization]
while [terminating condition(s)]:
     [loop body]
     [iteration initialization]

I think that it's important to remember that everything involved in 
programming is a trade-off -- everything has a cost and a benefit.  In 
some cases the cost is negligible and the benefit large; this is 
usually the case for structured programming techniques.  In other 
cases the benefits are moderate and the cost is large; this is 
typically true of "goto" and similar structures (or should I say 
anti-structures?)  But there's always edge cases, where different 
beneficial techniques (blocks should have a single exit, code 
duplication should be avoided) end up conflicting, and sometimes it's 
best to find a compromise that follows the intent behind both 
techniques, even if it doesn't adhere to the specific recommendations.

Of course, all of this is just my opinion, and I've had considerably 
less education in this area than Alan has, so... standard disclaimers, 
YMMV, etc, etc  :)

Jeff Shannon
Technician/Programmer
Credit International