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

Simon and All,

You may be interested in a recent article published in Computer World about
elegance in programming.  It compared a beautifully written piece of code
to Michalangelo's Pieta!  

I was shocked.  Despite all lip service to the contrary, it has always
seemed as if the whole ideal is to slam the code out ASAP.  Then later, the
programmer gets the added bonus of being a fire fighter. (firefighter =
hero).  

I could probably count on one hand the number of people who have told me
that my code is 'elegant' or 'easy to maintain'.  And of course, those were
other programmers, not users or management.  Good program design is rarely
noticed!  Time to develop *is*.

I have never seen anyone try to measure the maintainance cost of code. 
Instinct and experience tells me that a well written program has a lower
cost of future maintenance, but how can this be proven?

As for these op codes, I don't use them for new code, but purity really has
nothing to do with it.  There are better tools at hand. Maintenance of
existing code is something else entirely.  My motto there is, If the shoe
fits, wear it, but tread lightly with it.  Meaning, if inserting a CABxx
will do the trick because that's how the original programmer structured the
code, then I CAB.

Just another 2 cents,
kk
___________________
Kathleen Kostuck   
pager (414) 402-0820       fax (414) 495-4986
kkostuck@execpc.com
AS400 Solutions
___________________

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