[Tutor] Multiple exits in a function...

[Alan Gauld]

> 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.

No, its not because the current thinking is the opposite.
However I have not seen any hard data to suggest that
it is correct, whereas several studies in the 70s showed clear
differences in comprehension in the pure structured approach.
That's why Wirth and Dijkstra advocated it, it wasn't their
personal taste it was the result of detailed study of
programmer behaviour!

> 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.

The maintenance issue is the biggest one from my personal view
but...

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

This is actually the worst of all worlds. The while loop purports
to be an infinite loop when it clearly isn't and now to understand
how the loop terminates at all we have to read the internal block
(which for quick program comprehension we shouldn't need to do!)

What this style does is moves away from the idea of Python being
executable pseudo code because it hides the loigic of the code
inside an if test - a branch - which is embedded in a loop. But
the loop - which is logically what is happening, not a branch
- carries absolutely no semantic value whatsoever.

> 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.

Yes inside a block of code ayt a lower level than the current
one - we have broken the structure of structured proigramming
which is all about the ability to read the code clearly at each
level of abstraction. We have now forced the reader to drop
a level of detail just to understand a higher level. Its very
close to introducing a GOTO - and Kernighan said as much when
he introduced it to C - but not quite...!

> 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.

That's true but you have to "go fishing" to find it.

> 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.

There is a separate type of lop for this type of exit supported only
(so far as I know) by ADA. Code Complete describes it in detail
and shows how to emiulate it in various other languages. It looks
a lot like this.

BTW, I'm not as opposed to break/continue as I probably sound.
But someone asked why it ewas considered bad in principle.
I'm merely stating the pure structured programming view!
Like everything you have to apply some intelligence. However
its worth knowing that just because lots of folks do something,
it may not be the best thing! And until somewone carries out
some rigourous studies to show that the break approach works
as well as single exit I will continue to use breaks sparingly.

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


And thats almost exactly how the ADA loop construct looks.
But it formalises the if test. However it also has a unique
key word which avoids implying that its a while forever loop...

> the letter.  One can look at this as a spelling variation of a
> do...while...repeat loop -- AFAIK

Its a fudge because Python doesn't have such a structure.
The key point about a while loop is that it should be used
when we don't know whether we ever want the loop to execute
at all. The repeat loop by contrasat always executes *at least once*.
So there is a clear semantic difference between the two.
In Python if you need a loop that always executes at least
once you are forceed into these sorts of fudges.

> structure Alan is recommending, which would be similarly summarized:
>
> [iteration initialization]
> while [terminating condition(s)]:
>      [loop body]
>      [iteration initialization]

Thats correct, its the standard while loop behaviour.
The initialisation is logically part of the block since
of the block was not self modifying the loop would never
terminate and the explicit first initialisation is a vital
part of the readability of the structure.

> 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.

Absolutely, and we mneed to understand the trade-offs. In this
case the trade off is between rapid comprehension and double
maintenance.

> best to find a compromise that follows the intent behind both
> techniques, even if it doesn't adhere to the specific
recommendations.

Or make an informed choice to suit the actual situation.

> Of course, all of this is just my opinion, and I've had considerably
> less education in this area than Alan has,

Hmm, I've just read a lot of books... :-)

And as I said above i'm much less religious about this issue in
practice than I am in principle!

Alan G.