|
Yawn... > ---------- > From: Simon Coulter[SMTP:shc@flybynight.com.au] > Sent: Friday, April 24, 1998 8:32 AM > To: MIDRANGE-L@midrange.com > Subject: RE: ILE RPG:Is the use of ITER & LEAVE Structured > Programming? > > 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 > +--- > +--- | 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-2024 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.