I'm defending Kent's example...
being able to shut down so coldly is a mighty fine feature of MPE, going
going gone soon, at which time it will become just as important use perform,
not go to, even for shutdown routines. (this CALL QUIT (an external
perform) example is good because even after you lose this source code, you
can engineer QUIT to nicely shut things down, closing files, sending
messages to your 2-way wrist TV, etc.)
but what you're pointing out is that no clue is left for debugging from this
lazy-programmer's (example) CALL QUIT using 21. But actually the 21, if
unique, saves that lazy programmer's butt - it's very easy to find, and now
you know what lazy code was worth making a little bit smarter, such as What
image error? So yes, he knew it was sloppy when written, but the time saved
easily makes up for the one-extra-compile needed to improve the clues!
Perform rocks, and really rocks once you have EndPerform. Ditto IF,
EVALUATE, all of them.
Basic's discouragement vs GOTO is probably what's kept it alive - crummy
code can be fixed without having to first turn spaghetti into ravioli.
Got a weird bug in a COBOL program? 1st item: look for GO TO, a very sure
signpost of crummy if not quite ancient code.
Tracy Pierce
> -----Original Message-----
> From: Shahan, Ray [mailto:[log in to unmask]]
> Sent: Friday, March 12, 2004 7:25 AM
> To: [log in to unmask]
> Subject: Re: GO TO
>
>
> Kent, I'm surprised that a person who stands behind the
> 'never use a GO TO'
> would shut down a program so coldly, and without closing files, error
> tracing/tracking statements, etc.
>
> I think your example bears out that bad code is bad code
> because it's bad
> code, and not because it has a GO TO statement in it.
>
> BTW, Kent, I'm picking on your example, not you or your REAL
> code. ;-)
>
>
>
> Ray Shahan
>
> Life is not a journey to the grave with the
> intention of arriving safely in a pretty and
> well preserved body, but rather to skid in
> broadside, thoroughly used up, totally worn out,
> and loudly proclaiming:
>
> -- WOW!!! What a Ride! --
>
>
>
>
>
> > -----Original Message-----
> > From: KENT WALLACE [SMTP:[log in to unmask]]
> > Sent: Friday, March 12, 2004 9:06 AM
> > To: [log in to unmask]
> > Subject: Re: [HP3000-L] GO TO
> >
> > No.
> >
> > IF IMAGE-ERROR
> > CALL INTRINSIC "QUIT" USING \21\.
> >
> > Kent Wallace
> >
> >
> >
> > >>> Jeff Kell <[log in to unmask]> 03/11/04 05:48PM >>>
> > KENT WALLACE wrote:
> > > Hmmmm
> > >
> > > I was told in 1986 when I worked at Boeing, never to use
> "GO TO"'s.
> > > I have had this discussion off the list. I have written a few
> > > languages and have compiled the following list.
> > >
> > > Language USE of "GO TO"
> > >
> > > COBOL It's a sin, some use it to exit paragraph
> but I won't.
> >
> > I have one major bone to pick with this one, and that is for error
> > handling. Sure, you can check IF NOT SUCCESSFUL PERFORM IMAGE-ERROR
> > even though you'll never come back (IMAGE-ERROR might, for
> example, do a
> > DBEXPLAIN then STOP RUN).
> >
> > In such cases, I think it is much more proper (and sensible) to just
> > bite your lip and GO TO IMAGE-ERROR.
> >
> > I suppose the purist would:
> >
> > IF NOT SUCCESSFUL
> > PERFORM IMAGE-ERROR,
> > STOP RUN,
> > END-IF.
> >
> > :-)
> >
> > Jeff
> >
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> >
> >
> >
> ==============================================================
> ==========
> > This e-mail message has been scanned for Viruses and
> Content and cleared
> > by School Specialty's email filtering solution.
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
