RE: NOTO (or "no GOTO in FreeForm RPG")

<Snip> from reeve
(deep breath) What bothers me about this kind of solution is that additional
logic is being introduced to control program flow.  Yes, CABxx and CASxx
meld logic and branching, but I'd consider their (let's include ITER, LEAVE,
and LEAVESR in the grouping) use to be in the second order of complexity
while a simple GOTO is the first order of complexity.  Understanding how a
SELECT group works is not intuitive.  
Scott's solution is an excellent template.  However, logic is not required
to figure out what GOTO means, and in the interest of discussing the
presenting problem in isolation, I'm assuming a given program's coding
technique did not include a side order of marinara.
</Snip>

I have been working in a shop that has code from 25 years ago. IMHO the
goto's represent a big problem in this code. Once you use one goto it is
very hard to avoid using another goto without re-coding the previous
goto(s). This perpetuates 'Spaghetti Code' that is difficult to maintain.
With For, DOW, DOU loops and standardized good programming practices, "RPG
IV Style Revisited" by Bryan Meyers, this problem is virtually eliminated. I
admit there is a learning curve for those that are not fluent with this
style of coding.
When I picked programming as a profession, I knew that education would be a
continuing part of my career. When something new comes along, (or in this
case something tried and proven) we need to analyze the benefits that it can
give us and use it to its best functionality.


<Snip> from reeve
My application package, currently running 900,000 lines of RPG in 1,500
application programs (there's a lot of reusable code), features a large
number of application panels individually supported by a unique help panel
and a combination of standard and panel-specific command keys.  I've done a
fair amount of white-board and back-of-the-envelope scribbling to figure out
a "better" way that works for the application and for what my customers
expect; so far, my standard template with "just enough" GOTO's (exclusively
for display file management) holds up well.  Program flow is a key part of
any business application, and I'd suggest it's just as important as the user
interface design and the editing/processing functions.
</Snip>

Again we are dealing with different styles here. I would have to say mine is
better (VBG - I'm not stuck on myself at all). I believe that all code
should be short and modularized. That keeps logic reusable and easy to
group. Again, there is a learning curve to doing ILE. I feel this form of
programming saves time and makes it easier to maintain. (Instead of several
locations to change certain logic such as retrieving an Items price, you
only have to change one service program)


Bryan K. Merrell (The GOTO Hater)
bkmerrell@xxxxxxxxxxxxxxx

You can't argue taste, religion, politics, or application development. In
fact, application development is a superset that includes the other three,
which makes it very dangerous indeed.
           Timothy Pricket Morgan - MidrangeServer.com