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

[Dave Mahadevan <mahadevan@xxxxxxxx>]

Leland, David wrote:

> Yawn...

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



--
Thank You.

Regards

Dave Mahadevan.. mailto:mahadevan@fuse.net


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