Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!oberon!poisson.usc.edu!mlinar From: mlinar@poisson.usc.edu (Mitch Mlinar) Newsgroups: comp.lang.c Subject: Re: goto's in C: an opinion... Message-ID: <3435@oberon.USC.EDU> Date: Sat, 18-Jul-87 02:09:31 EDT Article-I.D.: oberon.3435 Posted: Sat Jul 18 02:09:31 1987 Date-Received: Sat, 18-Jul-87 19:11:51 EDT References: <3289@bigburd.PRC.Unisys.COM> <7571@beta.UUCP> Sender: nobody@oberon.USC.EDU Reply-To: mlinar@poisson.usc.edu.UUCP Organization: University of Southern California, Los Angeles Lines: 95 Keywords: C, goto, style In article <7571@beta.UUCP> hwe@beta.UUCP (Skip Egdorf) writes: >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... > Hmmmm. Methinks I smells a fanatic ... >> >> 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. > which also clearly increases the code size (even if only a little), but let's read on > 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 Given even your rough example, you have not proven anything to me yet. > 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What does this mean? I could take this to mean the code is HARDER to read, has LONGER source, or just plain wrong. > >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! > Well, Skip, you have not given me anything concrete to work on. Before you get all steamed up, let me say I agree with you *in principle* and I also strive quite hard to keep goto's out of the C code (and am over 95% successful, if I had to take a stab at the actual stats). However, there are some things I think you over-dramatized: (1) (Sub)programs without GOTOs are NOT always more readable. (2) Similarly, STRUCTURED code is not always easier to read. I have seen some pretty STRANGE structures which are "curable" (I know you hate the use here) by the addition of one GOTO. I have watched programmers beat themselves up on this one... (3) THERE IS *NO* GENERALIZATION THAT CAN BE MADE REGARDING CODE SIZE. I can give you HUNDREDS of examples (and bury your mail system :-) that clearly show a GOTO produces less code size, and I can give you a hundred more where STRUCTURE clearly produces the smaller code. It is dependent upon the function being implemented. (Please show me how a structure made more readable by moving a piece into a subfunction can produce SMALLER or FASTER code. At BEST, there is a CALL/RETURN opcode set and associated delay.) Again, I *agree* with the principle, but be realistic! I always strive to dump GOTOs in favor of structures REALIZING that code size may NOT go down, but that MAINTAINABILITY increases. I often "kick back" code which I feel has unnecessary GOTOs to the originator; since most of the time they are NOT needed. But to declare that GOTOs are NEVER acceptable is pure horse-puckey. (I am not sure the "grand master" was in favor of stamping them out altogether, I *believe* he felt the way I do - it is too easy to use GOTOs to get the code working rather than planning and structuring the program correctly - "GOTO disease" - and should only be used WHERE THE CODE WARRANTS IT.) There is a nice class of decision trees which can NEVER be implemented smaller in a structure and and appear MESSIER when in a structure (to me anyway) versus just a couple labels and GOTOs to "help the structure out". I would be happy to drop just one of these on the net if you have trouble believing me. -Mitch