On Tue, Mar 8, 2016 at 12:16 PM, Vernon Hamberg
<vhamberg@xxxxxxxxxxxxxxx> wrote:
You pays your money - you takes your choice!
I prefer priming a DOW loop with a READ of whatever sort - I don't really
like doing a LEAVE in the middle for EOF condition - seems too much like a
GOTO abuse.
But this is personal taste for the most part
Use of LEAVE is indeed personal taste. But it's definitely not GOTO
abuse. It was specifically put into the language to provide very
well-defined and limited behavior. You can't use it to jump to an
arbitrary location. LEAVE takes you out of the innermost enclosing
loop. Period.
LEAVE, ITER, and LEAVESR exist precisely to serve as safe and sane
jumps. Lots of languages have equivalent statements. The point is that
these limited jumps should cover all or nearly all justifiable use
cases for GOTO, thus attempting to kill GOTO in a similar way that
%EOF and friends try to kill indicators.
Now, it so happens I also use a "pre-read" and a single %EOF test in
my loops, but for a different reason than you seem to. It's because I
find that redundant testing is uglier (and more verbose) than
redundant reading. That's definitely a matter of taste. One problem
with this kind of loop is that things get awkward if you need to use
ITER in multiple places in the loop. You either have to precede each
ITER with a READ (more read redundancy), or manage an increasingly
unwieldy forest of nested IF..THENs.
Of those two options, I choose always preceding ITER with READ (which
is 2 lines for each jump).
But my actual preferred method of handling intricate loops is just
heresy: I use GOTO *instead* of ITER, and toss in a tag just before
the loop-ending read! (This results in one line for each jump, and
less nesting, for the price of one extra line near the end of the
loop.)
It's actually pretty readable. Excessive verbosity and excessive
nesting are enemies of readability. But I fully understand if GOTO is
out of the question. To paraphrase an old IBM-related saying, "no one
ever got fired for avoiding GOTO".
John Y.
midrange.com
