RE: GOTO statement considered harmful (was Is this the Free-Format that we asked for?)

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