RE: GOTO

I must admit to a slight turn-on in the fact that this topic is being 
discussed. These type of brainy issues is what drew into programming to 
start with.

FWIW, here's my 2 cents.

1:

GOTO, in the year 2000, is relevant only when talking history. All modern 
programming languages (well...except assembler) remove the need to even 
consider the use of it. It's still there, IMO, as a museum piece.

Old code? Well I've changed my position. I personally believe that, 
with  RPG 2/3 programs, making modifications result in more readable code 
when the style of existing code is followed.

If any of you all remember that D.H. Dial Accounting system???, then 
hopefully you will agree that, although the author used the best language 
features available for the time, the code is archaic. GOTO's, Level 
indicators, weak routine names, etc., was the rule. However, the author was 
amazingly consistent---Once one learned his style, you could be sure that 
his methodology would be used in every program.

So, when making mods, I found that when the author's style was violated, 
the code was "violated". Sure, my mods used superior construction 
techniques, but the next guy behind me would have to pause to absorb my 
techniques, while the archaic (seemingly) construction flowed like candy to 
him.

Lesson: Unless the code is total linguini, use the existing construction 
methods when making mods, even if GOTO's, LEAVE's, & ITER's, repeating 
structures, etc., are employed.

Along this same line, I see no valid reason to convert RPG 3 code to RPG 4 
if the RPG 3 code works. How could any such project be justified? If 
programmers Peter, Paul, and Mary are used to working on program X, written 
in RPG 3 (or RPG 2 for that matter), why would one introduce the potential 
for future coding errors by converting program X to RPG 4? I see no logic 
here, but that's me.

2:

GOTO is valid so long as its use does not violate the single-entry, 
single-exit test. I am not advocating its use, I'm merely stating this to 
feed my ego :-)

One poster mentioned that if any of his programmer's used a GOTO, he'd sit 
him down and explain structured programming techniques to them. I was going 
to be a smart butt and say, "If one of your programmer's had the propensity 
to use a GOTO, then how did he get hired to start with?". But, I thought 
again: Given today's event driven programming model (that is, 
institutionalized spaghetti logic), what programmer out of college today 
would know anything about structured programming anyway? Probably not many.

3:

I don't quite understand the hoopla over free-form code. One thing that RPG 
has going for it is the ability to visually see all statement comments 
lined up real pretty. One can, provided that standards are in place, 
determine how a program works by reading the comments only (like a story). 
With free form languages, your eye bobs back and forth trying to decipher 
what is code and what is a comment---very tiring to the eye.

I believe RPG 4 offers the best of both worlds. We get some freedom to code 
statements the way our brain works, while at the same time, we still have 
the nicety of lining our comments up so the next dude can try to understand 
what the heck I was doing.

Wynn


At 05:51 PM 11/3/00 -0500, you wrote:
>Scott Klement wrote:
>
> >On Thu, 2 Nov 2000, M. Lazarus wrote:
> >
> >> >On the subject of GOTO's, yuck.  Remove them.  Even with RPG IV in its
> >> >current state, if one of my programmers is using GOTO's I sit down and
> >> >teach him program structure.
> >>
> >>   You're assuming that we all have the luxury of never maintaining old,
> >> ugly code that, for various reasons can't be completely rewritten and
> >> tested.  There has to be a good reason to remove something from the
> >> language, other than to force everyone to write better code.  If
>someone's
> >> a poor programmer, making GOTO's unavailable will not magically make them
>
> >> better.
> >>
> >
> >Old code that can't be rewritten will still be in fixed-format style,
> >not in the new free-format syntax...  Old code really isn't an issue
> >with the free-format stuff at this time.
>
>Scott,
>I greatly respect your opinion and wish to heaven I could agree with it.
>Old code is everything.  A typical chore for me is to take existing RPG III
>code, CVTRPGSRC it, eyeball the code I need to change (and pray it's a
>subroutine!), add my changes using RPG IV syntax; converting my subr to a
>proc, etc.  I end up with a strange hybrid of 500 lines of untouched RPG III
>code and a few dozen shiny new RPG IV lines.  I don't want GOTO for new
>development, I want it so I can perform maintenance activities without
>having to completely re-design old code.  That's what we're talking about.
>The problem with GOTO is that it represents sloppy design, sloppy thinking.
>
>
>RPG IV as it stands is MUCH better than RPG III basically because of
>subprocedures.  I can finally use local storage.  Oh, and RealVariableNames!
>Adding free format is absolutely icing on the cake; wonderful!  Now I can
>use indenting and whitespace to make the code even easier to maintain!
>Bravo, Toronto!  Yet, the way it stands, I won't be able to use free format
>in my maintenance activities because of that crummy GOTO that was used (and
>abused) in 1980.  Yes, yes I can drop out into fixed, but that destroys the
>look of the free form, and the look is the raison d'etre for free form
>calcs!
>
>In essence, that GOTO is the reason I will be forced to use fixed; the
>reason my old code can't be re-written.  But I take great cheer knowing that
>I can use free form in my new stuff!  Yippee!
>
> >5 years from now, however, there will be old, ugly, goto-ridden code
> >in the free-format syntax if "GOTO" is allowed on free-format specs.
> >Not having GOTO's will force people to learn to code properly!
>
>This is why I wish I could agree with you!  You are 100% correct.  Backward
>compatibility is a blessing (old "investment" is preserved) and a curse (old
>crummy code is preserved for future maintenance nightmares.)
>
>By the bye, GOTO is not the demon that Mr Dijkstra was railing against; it
>is leaving a top-down construct early.  His example was to imagine a process
>whereby you count the people entering a room.  There is a small interval
>between the time a person walks in, and the time your program increments the
>counter.  This is a window of uncertainty where your program doesn't match
>reality.  You need to ask the question "did the count get incremented yet?"
>
>Imagine the same scenario with GOTO (or LEAVE or ITER) in the code above the
>place where we increment.  Now, looking only at the incrementing code, can
>you tell if it has been executed or not?  Nope.  You must scan the code
>above it to see if we left the construct early.  This opens the window of
>uncertainty more.  Using a single early exit plants the seed of doubt.  The
>more you use, the greater the doubt and the more difficult to find all the
>exit points and why we left early.  We need to keep all those conditions in
>our head while working this portion of code.
>
>Now, I can't speak for everybody, but I can't keep track of a dozen exits
>(don't count this one because person was left handed, person had red hair,
>person had black socks, person not from Canada, etc.)  What should happen is
>a separate construct to "validate" that the person should be counted, and
>then invoke the incrementing code.  It's a matter of a construct doing one
>thing and one thing only.  Use of early exit is generally a sign that the
>code can be decomposed further.
>
>LEAVE and ITER are considered less hazardous because they always work in one
>direction, and they can only branch to a single TAG.  Mr Dijkstra would
>probably agree that they CAN be less hazardous, but they still create the
>window of uncertainty: did THIS code execute or not?
>
>Back to why GOTO is useful in free form code: John has given the very common
>example of an error routine, whereby we're going to validate some input
>against a dozen possible errors and we want to quit checking when we hit the
>first error.  The classic answer is a series of IF statements with a GOTO to
>drop out of the routine when an error occurs.  Real world practicality vs.
>Ivory Tower ideology?
>
>Here's an error checking routine snippet that works for new code without
>branching:
>c                   eval      rc=checkLowLim(testNumber)
>
>c                   if        rc = 0
>c                   eval      rc=checkHighLim(testNumber)
>c                   endif
>
>c                   if        rc = 0
>c                   eval      rc=checkSign(testNumber)
>c                   endif
>
>Dean, GOTO (or other early exit) is not REQUIRED, is it?  Not in new code,
>anyway.  In the maintenance world (Twilight Zone) I inhabit, I'm much more
>likely to see John's example:
>c                   if        testNumber<lowLimit
>c*                  mark or handle error
>c                   goto      stopChecking
>c                   endif
>...
>
>Now I need to add a check for the value of the sign.  Do I re-write (and
>disturb) the whole routine or do I use GOTO like my predecessors and disturb
>the code as little as possible and reduce the maintenance risk?
>
>Moving the code from RPG III to RPG IV didn't disturb the code:
>C     NBR           IFLT      LOWLIM
>C*                  mark or handle error
>C                   GOTO      STPCHK
>C                   ENDIF
>
>But I can add my new sign checking code right after it without impacting the
>original design (as bad as it was, it DOES work!):
>C                   if        NBR < 0
>C*                  mark or handle error
>C                   goto      STPCHK
>C                   endif
>
>Converting the original code to free form would have been nice:
>if NBR < LOWLIM;
>//                     mark or handle error
>goto STPCHK;
>endif;
>
>But because of the lack of GOTO, I'll need to keep it in it's original form.
>Oh, well.  It's not the end of the world, I guess; it IS old code, after
>all!  But I see so much of it, it sure would be nice to make it a bit
>prettier...
>
>Buck Calabro
>Aptis; Albany, NY
>"Nothing is so firmly believed as
>  that which we least know" -- Michel Montaigne
>Visit the Midrange archives at http://www.midrange.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
>+---

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