Re: No Go To's Forever!

[Robert Dewar <robert_dewar@my-deja.com>]

In article <38D81DF6.D4AA73FC@lmco.com>,
  william.dale.jr@lmco.com wrote:
> Line after obscure line. Awful crap.  Life is too short
> to deal with this stuff.

Yes, but showing an example of a feature being misused is not
an argument for never using the feature, unless you are
incapable of distinguishing good from bad use.
>
> I can confidently say I have never used a GOTO in Ada. Never
> had to.

No one ever *has* to use a GOTO, there are always other ways
to write things, and indeed you can't find an example where
the prohibition of gotos severely damages the code. You can
certainly find cases where the use of a goto clarifies the
code (e.g. the simple use for a 'continue' function in a loop,
where "goto Continue;" is clearer than rigging up an extra
if to skip the rest of the loop in many situations.

What is interesting to me is that I often find that people
like no-goto-Bill are actually allergic not to the notion
of a goto (which would make some sense) but to the actual
keyword GOTO, and are still quite happy to do a RETURN or
EXIT from a deeply nested structure (or even (mis)use a
RAISE statement to get a goto without using the dreaded
keyword. Now if no-goto-Bill says that he would NEVER EVER
use such horrible things, at least he is consistent :-)

I once was looking at a COBOL program, where I found

PERFORM CLOSE-FILES

in a deeply nested structure. I was puzzled because I could
not see any way the program could continue after return from
CLOSE-FILES. Digging into many levels of calls, I finally
found a STOP RUN. statement, so in fact the PERFORM could
not return. The code would have been far clearer if it had
said:

GO TO CLOSE-FILES

I asked why this was not done -- "Oh, we are not allowed
to use GO TO in our programs" was the absurd reply!


Sent via Deja.com http://www.deja.com/
Before you buy.