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



| -----Original Message-----
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement

| > Scott's solution is an excellent template.  However, logic is
| not required
| > to figure out what GOTO means, and in the interest of discussing the
| > presenting problem in isolation, I'm assuming a given program's coding
| > technique did not include a side order of marinara.
|
| Writing code without GOTOs is not a new concept that appeared with /FREE.
| It has been consider a "Best Practice" to code without GOTOs for 20 years
| already.

This is, in actual fact, only partially true.  I'm sorry if this causes any
embarassment to either Hans or Rick, whom I both respect.  ALL conditionals
are, in actual fact, "GOTO's", including an "IF".  Some are easier to
maintain than others, and well-designed GOTO's are, in fact, EASIER to
maintain than poorly designed "ITER" and "LEAVE's".

I will say that, iirc, I haven't used a goto (except in contracting with a
client that uses them), since 1981 m'self.  For the same reason, I do not
use ITER or LEAVE, but would use a LEAVESR anytime.  I use a, in essence,
"GOTO" by using EXSR ENDPGM to bail out of screens.

It is absolutely false to believe a GOTO is bad, but an ITER or LEAVE is
good, in all cases by definition.  At the same time, it is absolutely true
that these are a matter of style, And a CONSISTENT style in ANY shop is
better than inconsistent styles, but not all styles are equal.  (Not saying
my style is all that good, either, but nonetheless these facts are gonna be
plainly self-evident to some folks.)


| -----Original Message-----
| From: rpg400-l-bounces@xxxxxxxxxxxx
| [mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of
| rick.baird@xxxxxxxxxxxxxxx
| Sent: Friday, November 21, 2003 1:18 PM
| To: RPG programming on the AS400 / iSeries
| Subject: Re: Infinit loop in /free
|
|
|
| Thanks for that endorsement Hans.  despite thier seeming kinship
| to goto's,
| I love 'leave' and 'iter'.  They make my job so much easier.
|
| I hate complicated and nested compound if/else/ constructs.  They are
| confusing and prone to error.
|
| My typical exfmt loops look much like this seudo code - the nesting never
| exceeds 1 level past the do loop, and it's obvious what happens under each
| condition.
|
| I'm either going to go directly to the top of the do loop, exit the do
| loop, or continue with the next executable inside the do loop.  No setting
| of intermediate variables, no checking-again of variables I've already
| checked once.
|
| (also, note my never-ending-loop of choice ;)
|
| begsr
|
| dow 1=1
|   exfmt screen
|
|   select
|   when *inkc
|     eval *inlr = *on
|     return
|   when *inkl
|     leave
|   when *inkd
|     exsr prompt
|     iter
|   when oneThing
|     exsr DoOneThing
|     leave
|   when anotherThing
|     exsr doAnotherThing
|     iter
|   when somethingElse
|     exsr doSomethingElse
|   other
|     exsr doTheOtherthing
|   endsl
|
|   exsr editscreen
|
|   if errors
|     iter
|   end
|
|   exsr updatefilefromscreen
|
|   if not stayingHere
|     leave
|   end
|
| enddo
|
| endsr
|
| ----Original message-----------
| <snip>there's absolutely nothing wrong with LEAVE and ITER. Even if you
| subscribe to the tenets of "structured programming", when using LEAVE or
| ITER, your loop still has a single entry and a single exit. By
| explicitly exiting a construct early, you can often avoid additional
| levels of nesting.
|
| Cheers! Hans



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.