The final word on GOTO (Don't I wis

[Kim Letkeman]

In article <598 at crdos1.crd.ge.COM> davidsen at crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:
> In article <1017 at kim.misemi>, kim at kim.misemi (Kim Letkeman) writes:
> |  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. 
>   Size and structure are not exclusive. A switch within two for loops
> seems like a reasonable structure to me, but it can contain a lot of
> cases. If the code for each case is small, say 1-2 statements each,
> using a table lookup and procedure per case can add a lot of overhead,
> and encourages pollution of global namespace to make variables
> available.

This is a fairly rare occurence in my experience. In a situation where
you have a couple of nested loops where the lowest level contains many
cases with only one or two lines each, a clean way in which to express
this is to separate the function being performed at the lowest level
into a separate procedure. (You can pass that procedure the data it
needs.) 

This leaves the higher level "control" procedure at a reasonable size
with its structure quite obvious. Essentially, this part of the goto
thread is about (IMO) software structure as it pertains to
readablility and maintainability. The optimization part of this thread
is a separate issue.

So, if we consider readability and maintainability as desirable
attributes (likely a general consensus), then anything that
contributes to that is also desirable.

Small procedures contribute.

>   All big procedures are not badly structured, and efforts to keep the
> lines per procedure down to some arbitrary limit cost time to write, to
> run, and to maintain.

True. A big procedure is not necessarily badly structured. But that
does not make it easy to read. In fact, a procedure that grows beyond
your immediate field of view (24 lines on terminals, more on listings
and workstations) is *automatically* harder to read since you have
less context within your immediate grasp.

Some procedures *must* grow larger than your normal field of view.
Granted. But this does not excuse someone who habitually codes 100
line functions or procedures. The circumstances in which a single
control procedure needs to be longer than say, 50 lines (which I
consider too large as it is) are quite rare.

If you examine almost any procedure of this size, you will see that it
performs functions at two levels of control. Or even worse, two
functions at the same level of control. Or really horrible, two
completely independent functions at the same level of control where a
switch passed in determines the action performed.

As a general principle, writing a single procedure to perform a single
function (task) is the whole point behind so called structured
programming.  Coupling and cohesion and all that.

So where does the goto fit after all this? It doesn't.

> |  I apologize if this message has a pious tone.
>   It certainly could be read that way...

True. But then so could anything written by someone with strongly held
beliefs. Especially if you disagree with that person's most basic
premises.
-- 
Kim Letkeman    uunet!mitel!spock!kim