Re: GOTO considered Satanic (was: Is there an ADA analogue to the C++ continue statement?)

[adam@irvine.com (Adam Beneschan)]

In article <3423AF1B.5152@i.b.m.net> dan13@i.b.m.net writes:

 > Any coding standard, or project commandment, or mindset, which
 >bars usage of GOTO *unconditionally* ... is ABSOLUTELY silly.
 >Yes, GOTO is to be avoided (as a goal), no sane person argues
 >this. Yet there are times when using a GOTO enhances the
 >readability - and thus the maintainability - of the code.
 >
 > Coding standards etc... should be thought of as *guidelines*;
 >with "violations" of the guidelines being vetted by some project
 >specific process.

You know, I wonder whether the whole debate over the GOTO has failed
to keep pace with the times.  Back in the 70's, when I started to work
as a programmer and when Dijkstra's paper was still a hot topic, many
of the seasoned programmers around were used to assembly-language
programming, and the other main languages of the time, COBOL and
FORTRAN, didn't have adequate looping and control structures as
today's languages do (including later versions of COBOL).  So it was
common to use GOTO liberally.  At least that's the case where I
worked; many of the older COBOL programs I had to work with truly
deserved the description "spaghetti code".  So those programmers
needed a lot of convincing to make major changes in their style.

Today, I don't think that's the case.  When I helped tutor a beginning
computer science course in 1980 (in Pascal), we didn't even teach the
students about the goto statement.  I don't know what the practice has
been at other institutions, but I'm willing to bet that most
programmers my age (36) or younger have been taught that GOTO is
something to be used rarely, if they haven't been taught that they
will be expelled from college if they write a GOTO.  And the languages
more likely to be used for teaching have much better control
structures than past languages, so that there should be much less
temptation to use GOTO as a crutch.

So I was disappointed to see the style guide say:

     guideline 

  -  Do not use goto statements. 

     rationale 

     A goto statement is an unstructured change in the control flow.
     Worse, the label does not require an indicator of where the
     corresponding goto statement(s) are. This makes code unreadable
     and makes its correct execution suspect.

The absolutist language "This makes code unreadable and makes its
correct execution suspect" hardly seems necessary.  Sure, you can use
GOTO to write unreadable code.  You can use any language feature to
write unreadable code.  But using a GOTO doesn't automatically make
your code unreadable, as this statement seems to imply.  Programmers
in the past often turned their code into linguine, but it seems to me
that this just doesn't happen as often today, due to the anti-GOTO
bias programmers are learning in school; and hopefully when a GOTO is
used, it's much more likely to be done in a readable fashion.

(Plus, I found the style guide's reasoning unconvincing.  They say
GOTO is unreadable because a label doesn't require an indicator of
where the corresponding goto statements are.  But an "exit" statement
is essentially a "goto" to the end of a loop, and loop statements
don't require an indicator of where the "exit" statements are, so how
does this logic show that GOTO's are more unreadable than EXIT?)

Anyway, my point is: This is the 90's.  The battle has been won.  It's
no longer necessary to take the attitude that whenever we see a GOTO,
we should let out a shriek and beat the offending insect to death with
a broom.  We can, and should, adopt a more moderate and less
absolutist tone, one that says that GOTO's are generally unnecessary
and should be avoided but may make code more readable on rare
occasions.

                                -- Adam