The final word on GOTO (Don't I wis

[Kim Letkeman]

In article <514 at crdos1.crd.ge.COM> davidsen at crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
>In article <4208 at cbnewsh.ATT.COM>, ijk at 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