|
Hello All,
I wish I could LEAVE this one alone (and believe me I tried) I have waited all
day thinking don't bother,
those who think GOTOs and LEAVEs and ITERATEs are acceptable aren't worth
arguing with; but I must give my
comments. I do not intend to get into a fight with anyone but here are my
views:
A few givens:
1) Structured operation codes in and of themselves do not make for a structured
program. I have seen the most
unmitigated crap use DOxxx and EXSR and the program is still a mess. That says
more about the programmer than
the program.
2) It is not the presence of a GOTO that is the problem but the lack of a
COME-FROM: that is how did I get to
this point in the code. There could be, and often are, many branches to the
same label and no return point;
that is simply sloppy.
3) All structured operation codes are in essence a compare and branch with the
compiler determining the return
point. That is the advantage; because the compiler determines the return point
there is structure.
4) Judicious use of GOTOs can accomplish all that structured operation codes
can but with less clarity (due to
the lack of a return point). The problem is that judiscious use requires
discipline on the part of the
programmer and few do it properly.
5) LEAVE and ITER are NEVER unconditional.
Now for my opinions:
CABxx is a GOTO and should be avoided because there is no return point
associated with it. Reasons why GOTO
is bad form were covered by Djikstra at least 20 years ago. Some of you
obviously haven't learned. CABxx can
be replaced with CASxx statements and gain a known return point. CABxx is
sloppy.
ITER and LEAVE are disguised GOTOs. The reason they are considered
'structured' operation codes is that the
target of the branch is controlled by the compiler therefore that point can be
determined by the programmer.
For that reason they are marginally better than GOTOs. However, in most cases
the following is true:
LEAVE is occasionally useful to terminate a loop but a little thought
can usually incorporate the
LEAVE condition into the loop test. Granted there are some conditions where
all you want is to exit NOW and
LEAVE handles that rather well.
ITER is hardly ever necessary. Simply inverting the test around the
ITER and changing to an IF means
that block of code will not be executed and the loop will iterate of it's own
accord.
For example: IF some-condition ITER can quite easily be written as
IF not-some-condition STUFF.
It may be a matter of preference but it has been my experience that the people
who think LEAVE and ITER are
acceptable AS A MATTER OF COURSE are the people who write shitty code.
Probably the same people who use GOTOs
and conditional indicators in RPG (or worse arithmetic resulting indicators).
They are generally muddled
thinkers and that is reflected in the code they write.
As programmers we are practicing a skill. That is 'programming on purpose'.
That skill should be constantly
honed. That requires certain care and responsibility on our part. Including
the dropping of outdated
techniques. Imagine for instance a timber cabinet for sale in an exclusive
furniture shop. The outside is
well finished and it looks good but when you open the drawers you see gaps in
the dovetail joints and traces
of glue. In my opinion that is not a well made piece of furniture, sufficient
care was NOT taken, and I would
not buy it. The same statement is true of programs: the fact that is works is
not a sufficient arbiter of a
good program -- that is simply to be expected. Maintainability is of prime
importance; after all that is
often the most expensive part of development; Cleanliness and elegance are
equally important.
Working code is what the users expect (unless they use M$ products)
Maintainable code is what the bean counters expect
Elegant code is what programmers should deliver for their own and their
peers satisfaction
Programming for expediancy is the lazy approach and is inexcusable. GOTOs in
all their forms are poor joints
and therefore suspect. They are indicative of lack of thought.
Every time a GOTO or equivalent operation is considered, reasonable thought
should be applied to why it is
necessary and whether a different approach would avoid them.
As for Toronto even considering a LEAVESR operation code regardless of the
small effort required to satisfy
the request ... words fail me! This 'op-code' can adequately be replaced by a
GOTO and a label on the ENDSR
statement if you must use it. It is not even necessary, it can ALWAYS be
replaced by an appropriate IF test.
In most cases if you need to bypass code in a subroutine then that code should
not even BE in that subroutine.
So (for those of you who have read this far) CABxx and GOTO should never be
used. LEAVE and ITER should be
avoided. Whether you disagree is of no interest to me whatsoever. None of the
arguments in favour of these
operaton codes has been persuavive, merely misguided.
Regards,
Simon Coulter.
//----------------------------------------------------------
// FlyByNight Software AS/400 Technical Specialists
// Phone: +61 3 9419 0175 Mobile: +61 3 0411 091 400
// Fax: +61 3 9419 0175 E-mail: shc@flybynight.com.au
//
// Windoze should not be open at Warp speed.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.