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