Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.misc
Subject: Re: The "evil" GOTO (Was: 25 Years of BASIC)
Message-ID: <13424@lanl.gov>
Date: 11 May 89 00:55:41 GMT
References: <6974@ecsvax.UUCP>
Organization: Los Alamos National Laboratory
Lines: 61

In article <852@umecs.cs.umu.se> christer@rachel.UUCP (Christer Ericson) writes:
> [...]
> One thing the code samples you presented do *not* prove is
> the acceptability of GOTO code with jumps longer than a few
> lines.  Sure, it's easy to see where a GOTO is leading when
> both the GOTO and it's target location appear right there on
> your 24-line screen, but when you are working on code of any
> significant size and complexity, the issue of knowing where
> the GOTO points to rears it's fugly head.  For an example,
> pretend this article is a code segment.  Now, quick, tell me
> where we're going...  ;')


Unfortunately, the _SAME_ problem exists when you introduce a boolean
to replace the GOTO.  If you can't see the use of the flag right away,
then its presence in your code is just as mysterious as the GOTO is
(ie. where is this niggly little flag variable used?).  Often you find
that the flag is used _several_ places - that's certainly not the case
with GOTOs.  When you find the place where a flag is used you have no
assurance that you've found the _only_ use.  The 'fan-out' of the 
GOTO is one, the 'fan-out' of the boolean is unbounded.

> Here's another code segment (label only):
> 
>      LOCATION:
> 
> Now, quick, tell me where we're coming from!  In many cases the mere
> existence of a label can be more confusing than the presence of a "goto"
> because it implies an unknown number of jumps from multiple unknown
> locations.  

Ok, now try this example:

      if (aflag) then
      [...]

Now, quick, tell me where aflag was set!  In many cases the mere
existence of a flag can be more confusing that the presence of a GOTO
because it implies an unknown number of paths through the preceding
code may have set the flag.  8')

Now, in truth, the 'fan-in' of a boolean and a label are exactly
of the same complexity.  Selecting mnemonic identifiers for either
will increase readibility.  So will the presence of appropriate
comments.  _BUT_, the real _MEANING_ of a flag is the union of
all the conditions which could cause the flag to be set - the real
_MEANING_ of a label is the union of all the conditions which could
cause a jump to it (or a flow to it).  Neither is intrinsically
simpler than the other.  Which _looks_ best to _you_ is a subjective
decision.

To be sure, GOTOs can be abused to produce spaghetti code.  Unfortunately,
flags and/or conditions can implement the _same_ spaghetti!  I have
seen well "structured" (no GOTOs) code in which the flow of control
bounces all over everywhere (lots of conditions and flags, lots of
IFs and CASEs, all inside a loop).

By the way, the POINTER in data structuring is isomorphic to the GOTO
in flow control.  The POINTER can be abused to produce spaghetti data
structures.  Any anti-GOTO fanatics out there want to ban the POINTER
too?