Path: utzoo!attcan!uunet!kim From: kim@kim.misemi (Kim Letkeman) Newsgroups: comp.lang.c Subject: Re: The final word on GOTO (Don't I wis Message-ID: <1017@kim.misemi> Date: 27 Sep 89 15:04:11 GMT References: <20324@<1989Sep14> <225800222@uxe.cso.uiuc.edu> <4208@cbnewsh.ATT.COM> <514@crdos1.crd.ge.COM> Organization: MITEL Corporation, Kanata, Ontario, Canada. Lines: 50 In-reply-to: davidsen@crdos1.crd.ge.COM's message of 26 Sep 89 12:19:16 GMT In article <514@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >In article <4208@cbnewsh.ATT.COM>, ijk@cbnewsh.ATT.COM (ihor.j.kinal) writes: >| Well, what if it took the NEXT poor programmer who maintains that >| program an extra week to understand what it does ??? Or even >| an extra minute ??? [each and every time it was examined - it might >| add up to a lot]. > It depends on what you use instead of the goto. If you compare a goto >against setting a flag variable and testing it to break out of three >levels of loop, the goto is certainly easier to understand, particularly ^^^^^^^^^^^^ >if the loops have a lot of code. If you use a goto where a break would ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >do it makes the code more subject to error (you can now mess up >placement of the goto or the label). If you have three levels of looping with "a lot of code" in them, then a goto versus a flag is hardly your biggest problem. If you keep your programs well structured, with *small* functions that fan out smoothly from control level functions to low level (working) functions, then this situation just doesn't arise. Only when you succumb to the temptation to add "just a little more" functionality to an existing function without properly restructuring it into its component functional units will you end up with rat's nests that require gotos to handle control flow. I apologize if this message has a pious tone. It is not intended to be a preaching article, but this thread has been filled with attacks on and defenses of gotos without really acknowledging the fact that a goto is usually the result of too much complexity in the control flow. The complexity arises (usually) when there isn't the time or inclination to properly structure the code in question. I have read and applied the concepts discussed within the book Software Tools (to name perhaps the most famous of this ilk) and it works. Code need not be ugly. It need not contain gotos (except in the most extreme of circumstances.) And optimization of that code by the compiler is a red herring if ever there was one. Code that is badly structured enough to require a goto already has macro algorithmic problems that can't be solved by a micro optimizer. (And as most know, macro algorithm problems account for orders of magnitude more execution time than the more micro compiler optimization problems.) -- Kim Letkeman uunet!mitel!spock!kim