Re: IMHO

Could someone please tell me what IMHO represents?  I'm beginning to feel like I
entered a chat room!
- cb

James W. Kilgore wrote:

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



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