× 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: %EOF - more on GOTO
  • From: "Scott Klement" <infosys@xxxxxxxxxxxx>
  • Date: 20 Jun 1999 16:02:49 -0500

John,

I understood and agreed with your original post about GOTO's, but I
think your example was the reason everyone is arguing with you :)

Your example actually made a case for using SELECT instead of GOTOs
rather than illustrating your point :)

I use GOTO in two situations, and they are:

1) To abort a subroutine in the case of an error.   In this case,
     my GOTO will refer to an ENDSR op-code, and not a TAG.
     I understand that a solution to this situation is currently
     in the works for the next release of OS/400, unfortunately,
     I use a CISC box, so it may be years and years before I ever
     get to use it :)

2) When I'm changing someone else's code.  Often beginner programmers
     don't have the experience to know how to structure their code
     so that goto's are unnecessary.  I've seen code where there will
     be an ENTIRE SCREENFUL of "ENDIFs" in SEU.   Good Lord!  Now
     I find a exception condition thats not being handled, and am
     faced with the choice of using a GOTO to adding more ifs and
     modifying existing IFs to properly handle my exception.  At
     this point, a GOTO is not only easier to code, its also easier
     to READ. :)

Perhaps this is also why I'm arguing for a format of RPG that
we can use indenting in :)

Scott Klement
Information Systems Manager
Klement's Sausage Co, Inc.


"John Taylor" <John.Taylor@telusplanet.net> wrote:
> Chris,
>
> Thank you for the refresher in STRUCTURED PROGRAMMING 101. ;-)
>
> However, my intent was to point out that the GOTO is not inherently
>  bad
> thing. The working example is an extreme simplification of the
>  validation
> routine. A single select is very clean in this case. In the real
>  world, the
> validations will generally be more complex, involving multiple IF's
>  and
> possibly some more SELECTs. That leads to nested SELECT statements,
>  which I
> try to avoid whenever possible because the fixed format tends to mak
>  it a
> chore determining where any given select ends.
>
> I think we share the same objective here - to make the code more
> readable/maintainable when we have to visit it again in a years time
> Personally, I find a nested IF/SELECT structure much more difficult
> follow than a routine that has easily identifiable "code blocks".
>
> I do reserve the right to change my mind and declare all branching
> statements as a product of the devil - if.. and only if - we see a
>  free form
> RPG that will allow me to indent those nested structures. <g>
>
> Oh, and one more thing.. Those people that use TAGS/GOTOS to perform
> loop - there is no defence for these people. They should be sentence
>  to
> hard time twiddling bits in machine language.
>
>
> John Taylor
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.