Re: the hoopla over free-form code (was GOTO)

No more comments on GOTO, everything that can be said about it has
been said I think.

Why free format instead of RPG style?

The biggest benefit to me would be indenting of logic blocks.

If Something
  If SomethingElse
    DoThisThing
  Else
    If ThisOtherThing
      DoThisOtherThing
    Else
      DoThisInstead
    EndIf
    If This
      DoThat
    EndIf
  EndIf
  Do This
EndIF

Is MUCH easier to follow than:

If Something
If SomethingElse
DoThisThing
Else
If ThisOtherThing
DoThisOtherThing
Else
DoThisInstead
EndIf
If This
DoThat
EndIf
EndIf
Do This
EndIF
  
Regards,

Jim Langston

Wynn Osborne wrote:
<SNIP>

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