Re: ILE RPG:Is the use of ITER & LEAVE Structured Programming?

Simon Coulter wrote:

> 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
> mostunmitigated crap use DOxxx and EXSR and the program is still a mess.  
>That says more about the programmer
> than the program.
>

Agree 100 %

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

What? If I code a routine to perform a function, there is no COME-FROM that 
would tell you which EXSR (assuming it
is executed from different locations) caused the program to end there.

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

Ok

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

Yes they are. (Unless someone slipped in a conditioning Indicator)

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

Agree

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

Agree (because of the MATTER OF COURSE)

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

Elegance should not be a factor. I have seen more "elegant" code that was BS, 
then I care to recall. Of course,
this may be because of different views on the definition of elegant. What I 
have seen termed as "elegant" has
often appeared as code where a college student had to show every trick he knew, 
in one program.

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

But remember, GOTO does NOT have a compiler controlled destination. LEAVESR 
will.

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

How about, only in unique situations where there is clear advantage, AND it is 
well documented!

> LEAVE and ITER should be avoided.

Once again, the advantage needs to be there to use these opcodes.  Once again, 
it must be documented. Let the next
guy know exactly why the opcode will be executed.

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

I think we should debate this face - to - face. Could you provide Airfare, so I 
can come to AU? <VBG>Caio,
Bob Larkin
Sleep-By-Day Software....<bg>

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

begin:          vcard
fn:             Bob Larkin
n:              Larkin;Bob
org:            <A HREF="HTTP://web.wt.net/~blarkin/">Larkin Computer Consulting</A>
adr:            <A HREF="http://web.wt.net/~blarkin/">Bob and Diana's Page</A>;;;Houston;TX;<A HREF="http://web.wt.net/~blarkin/">;United States
email;internet: blarkin@wt.net
title:          Systems Consultant
x-mozilla-cpt:  ;4104
x-mozilla-html: FALSE
version:        2.1
end:            vcard