× 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: "Leland, David" <dleland@xxxxxxxxxx>
  • Date: Fri, 24 Apr 1998 11:46:12 -0500

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