| Joe Zitzelberger 2004-11-17, 3:55 pm |
| In article <419A494A.D22CE3BA@mb.sympatico.ca>,
Peter Lacey <lacey@mb.sympatico.ca> wrote:
> Joe Zitzelberger wrote:
>
>
> Very well, let me be specific and explain how >>I<< do it, using a
> method which has never failed me.
>
> I always use numeric-prefixed paragraphs and section names (section
> names only for SORT input & output procedures). The numeric prefixes
> are unique and in strictly ascending order. Usually they are four
> digits but sometimes three (but NOT in the same program. Either/or).
> My PERFORMS look like this:
>
> PERFORM mnxx-something THRU mnyy-EXIT
> or
> PERFORM mnx-something THRU mny-exit.
>
> There have been a very few cases when I've had to violate this when
> using 3-digit prefixes, when I had too much going on in the performed
> range. VERY few. Maybe 20 in 30 years. In practice, usually the first
> three digits of the four-digit prefixes are the same for a given
> PERFORM.
>
> So it isn't as if there's much room to make a mistake when I'm coding,
> since for each new perform range I simply increment the mn by 1 or 5 or
> 20. I >>NEVER<< PERFORM any paragraphs inside a PERFORM range
> (sometimes referred to as "pathological PERFORM's, with reason). If
> logically two or more ranges COULD be performed in one statement - as in
> Joe's first line above - I don't: I PERFORM each range explicitly and
> individually (and of course in the correct order!).
>
> It always works.
>
> (If somebody working on one of my programs cuts and pastes across a
> range then it's their problem, not mine. As I always use copious
> comments, they would have to be fairly stubborn and unobservant to do
> that anyway).
>
>
> If you remove the "nothing but" then you are correct. If you insist on
> leaving it in, you're wrong. However, if a statement mustn't be used
> because it's a source of possible failures, then we aren't going to have
> very much left to work with, are we?
>
> PL
I'm not saying a statement shouldn't be used because it is a point of
possible failure. I'm saying that if two identical statements exist,
and one adds extra failure points, there is wisdom in selecting the one
that does not add failure points.
You say you already self-limit most of your THRU usage. That is, you
don't P/T over ranges of other performs or within a perform. And that
you explicitly code the P/T even if the routines are sequentially
located.
Following those rules, your code could always be rewritten this:
P/T way:
PERFORM 1000-STUFF THRU 1000-EXIT
...
1000-STUFF.
blah
blah
IF SOME-COND-FALSE GO TO 1000-EXIT
blah
blah
EXIT.
1000-EXIT.
EXIT.
P way:
PERFORM 1000-STUFF
...
blah
blah
IF SOME-COND-TRUE
blah
blah
END-IF
EXIT.
Your rules are exactly what the compiler would enforce for a simple out
of line perform. Only with the P/T way, the human writer has to enforce
those rules -- with the compiler it is always done.
The method may not have failed you -- but has it ever failed someone
working on your programs in a maintenance capacity?
|