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