Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!beta!hwe
From: hwe@beta.UUCP (Skip Egdorf)
Newsgroups: comp.lang.c
Subject: Re: goto's in C: an opinion...
Message-ID: <7571@beta.UUCP>
Date: Fri, 17-Jul-87 14:41:56 EDT
Article-I.D.: beta.7571
Posted: Fri Jul 17 14:41:56 1987
Date-Received: Sat, 18-Jul-87 15:02:09 EDT
References: <3289@bigburd.PRC.Unisys.COM>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 113
Keywords: C, goto, style
Summary: A stronger opinion

In article <3289@bigburd.PRC.Unisys.COM>, weiss@bigburd.PRC.Unisys.COM (Tom Weiss) writes:
> 
> Since now appears to be the time to express opinions about
> style/clarity, I would like to address my own pet peeve: the goto
> statement.

I love your comments Tom, now just be a bit more assertive...

> 
> There are very few legitimate uses for the goto statement,

  There are NO legitimate uses for the goto statement...

> ... C
> provides alternates for most of them.  While it is true that these
> alternates are no less evil than goto viewed from a structured
> programming perspective, at least they are more readable.

A large myth from the 70's, where structured programming was viewed
as "no gotos", was that forward jumps out of loops were not structured.
This is not true. A break transfers control to a known place and provides
just as structured a piece of code as a while leaving the loop on a false
condition.

I have been in "discussions" with programmers who claim that some piece of
code just written, containing only gotos as structuring elements, is
a structured program because it uses only proper constructs (implemented
with gotos) of if-then-else, looping, and sequences. This argument is
valid as far as it goes. Two problems exist with programs of this form,
or programs with ANY gotos.

 1. The major amount of effort in any production code is maintaining that
    code. As programmers modify code with gotos, lack of understanding
    of the entire structure of the program leads to local modifications.
    Additional jumps to local labels, and additions of code that span
    earlier structures not visible due to the goto-implementation
    cause Entropy increase, and the code becomes unstructured.

 2. While the author claims that the program is structured, no compiler
    can verify that the gotos are used to implement only the structured
    programming constructs. I don't believe my own assertions about the
    correctness of some un-verified piece of my own code. I will not
    believe someone else's.

> 
> Since C provides the break statement to break out of a loop, the
> continue statement to jump back to the top of a loop, the return
> statement to immediately exit a function, and access to system calls
> (e.g. exit) that can terminate execution in error handling functions,
> there are few 'legitimate' uses for goto.  The only one that
> immediately comes to mind is breaking directly out of a
> multiply-nested control structure.

And if such a structure is used, it can ALWAYS be improved by removing
some of the structure to a sub-function.

> 
> Once I was involved in rewriting a piece of code which contained a
> goto.
> ... story about re-doing a code containing gotos, and improving it...
>

Again, two points

1. When I moved from fortran and assembler to a MULTICS and PL/I, I found that
   I had stopped using gotos. I didn't do this on purpose. I just found
   that I never reached a place where I needed one. I began examining
   lots of other code and re-doing it without gotos. Sometimes this was
   hard, and involved a total re-design of the code (see below).
   I did find that in EVERY case the code got more understandable,
   more efficient, and shorter in both source and object form. EVERY
   case was a triple win, with no loss. I have never found a case
   where someone could provide me with a goto'ed code, and I could not
   improve it in all three areas. Anyone reading this who sends me some
   piece of garbage to improve, please understand that it will goto(sic)
   /dev/null. The reson is...

2. Just removing gotos by simple restructuring techniques is not sufficient.
   (If it were, a compiler could do it. Recall that this is the general
    case. Not just a few special cases, such as handeled by programs
    like 'struct'.)
   Goto lovers find it fairly simple to come up with code fragments that
   require extra state variables or extra levels of procedure call to
   improve. My removal of gotos sometimes required my return to the
   functional specification of the system and a complete re-implementation.
   (and yes, I re-implemented as little as necessary, so that this did
   not skew the results too badly. I do believe that the re-implementation
   affected only the goto-ness of the program.) I finally gave up on
   this as I felt, and now feel, that any program with a goto is poorly
   designed, badly implemented, and a sign that the programmer did not
   know what was going on.

To finish up...
In 1968 Dijkstra's "gotos considered harmful" letter in CACM caused
comments like "I don't really understand what he is saying, but I am
sure that it is important...".
Computer professionals who did not wish to be branded as fuzzy-headed
ivory-tower unrealistic dreamers were forced to take a moderating
position of "gotos are bad, but a few are ok, once in a while...".

It is time to reverse this. So, to make my position clear:

In any language that supports a complete set of structured constructs,
there is NO NEED for a goto, and the statement should be removed from
the language!
Languages that do not have enough control structure should be used only
with a pre-processor (e.g. Fortran and Ratfor).

					Skip Egdorf
					hwe@lanl.gov

Since most work at Los Alamos is still fortran, I am sure that these
views are not representative of my employer. More's the s thip