Re: %EOF - more on GOTO

["James W. Kilgore" <qappdsn@xxxxxxx>]

John,

I agree that the real world is a lot more complex than examples of code/style
technique.

IMHO, a SELECT is a IF/GOTO in disguise where the branch point may be pages
away.

In the school I went to we were taught usage of subroutines with a simple rule:
A routine (or section of mainline) either makes a decision or performs a
function but never both.  OK, it wasn't really a rule, just a guideline.

The addition of a row of dashes or whatever and comments can guide the follow-up
programmer to the fact that there is a transition from execution to decision and
back again.  It's a style decision.

Now it's not a LAW, but it does help one to organize a process to minimize
visual scan for logical function.  Personally I have yet to find a situation
where pages of SELECT can not be stated by a group of CASxx indicating the
decision process and separate routines to execute the decision.  And that
execution may be no more than another series of CASxx decisions.  It's a style
decision.

If an IF is followed by more code than the eye can scan completely, it should be
a subroutine.  It's a style decision.

This is really nothing more than another form of nesting by choice of style.  I
admit, ENDSR is just GOTO with a variable target.

And if one is willing to admit that SELECT/ LEAVE/ ENDSR/DOx/IF are just
elaborated GOTO's, GOTO or CABxx are no more than members of many branching
instructions to be used/abused by choice of style.

Now if the programmers that chose the spaghetti road would please leave the
building ....... ;-)



John Taylor wrote:

> Chris,
>
> Thank you for the refresher in STRUCTURED PROGRAMMING 101. ;-)
>
> However, my intent was to point out that the GOTO is not inherently a bad
> thing. The working example is an extreme simplification of the validation
> routine. A single select is very clean in this case. In the real world, the
> validations will generally be more complex, involving multiple IF's and
> possibly some more SELECTs. That leads to nested SELECT statements, which I
> try to avoid whenever possible because the fixed format tends to make it a
> chore determining where any given select ends.
>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the RPG/400 Discussion Mailing List!  To submit a new         *
* message, send your mail to "RPG400-L@midrange.com".  To unsubscribe   *
* from this list send email to MAJORDOMO@midrange.com and specify       *
* 'unsubscribe RPG400-L' in the body of your message.  Questions should *
* be directed to the list owner / operator: david@midrange.com          *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *