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