|
If (A<12) <do stuff> Else If(B=7) <do other stuff> Else If(A>4) <do something completely different> End End End Isn't it more obvious now? Taking it farther... If (A<12) <do stuff> ElseIf(B=7) <do other stuff> ElseIf (A>4) <do something completely different> EndIf Now it's even more obvious. And lastly... Select Case (A<12) <do stuff> Case (B=7) <do other stuff> Case (A>4) <do something completely different> EndSl Now it is really obvious. All 4 sections of code do the exact same thing. One using goto, one using if/else/endif one using if/elseif/endif and one using Select. The farther away from GOTO we get the more obvious flaws become. Regards, Jim Langston Mike Naughton wrote: > > RPG400-L@midrange.com writes: > >There would be things like... > > > > > >:Tag1 > > (Some Stuff 1) > > . > > . > > . > > If (B = 7) Goto Tag3 > > If (A > 12) Goto Tag1 > > If (A < 13) Goto Tag2 > > (Some Stuff 2) > > . > > > <!snip!> > > > >Is it obvious that (Some Stuff 2) will never get executed? > > Jim, > In fairness, the useless code is not caused by the GOTOs. Consider this: > > If (A<12) > <do stuff> > Else > If(B=7) > <do other stuff> > Else > If(A>4) > <do something completely different> > End > End > End > > Note that "something completely different" will never be executed for > 4<A<12, but you'd never know it just from looking at that section of code. > Put the nested test in a subroutine, and it gets even harder to track down > -- and I haven't used a single GOTO! And this is just a simple example -- > I hope it's obvious that it wouldn't be hard to come up with much more > complicated ones. > > I don't see how we get around the fact that for any reasonably complex > program (the kind we're paid to write ;-)), it's usually necessary to > spend time tracing just what-the-heck the program does (and doesn't do). > The only exception is when it has been written in a style (and using > standards) that you are thoroughly familiar with (and, IMHO, whether those > standards allow the use of GOTO is entirely irrelevant to the question of > how readable the code is). > > Mike Naughton > Senior Programmer/Analyst > Judd Wire, Inc. > 124 Turnpike Road > Turners Falls, MA 01376 > 413-863-4357 x444 > mnaughton@juddwire.com +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | 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-2025 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.