× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: ILE RPG:Is the use of ITER & LEAVE Structured Programming?
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 24 Apr 98 23:32:58 +1000

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

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.