http://www.azillionmonkeys.com/qed/goto.html

bg image(a097.jpg)

[comp]  GOTO

by Paul Hsieh
---------------------------------------------------------------------
Paul Nettle (a programmer at Terminal Reality), recently pointed out
some things written (by Microsoftie's no less) about the use goto and
the debate that so commonly ensues about it. Here's an excerpt of
what he posted to the rec.games.programmer newsgroup:

  Here's what "Writing Solid Code" (p. xxii) has to say on the
  subject of the goto statement:

  ---[excerpt begins]---
  That's not to say that you should blindly follow the guidelines
  in this book. They aren't rules. Too many programmers have taken
  the guideline "Don't use goto statements" as a commandment from
  God that should never be broken. When asked why they're so
  strongly against gotos, they say that using goto statements
  results in unmaintainable spaghetti code. Experienced programmers
  often add that goto statments can upset the compiler's code
  optimizer. Both points are valid. Yet there are times when the
  judicious use of a goto can greatly improve the clarity and
  efficiency of the code. In such cases, clinging to the guideline
  "Don't use goto statements" would result in worse code, not
  better.
  ---[excerpt ends]---

  And here's what "Code Complete" (p. 349) has to say on the
  subject:

  ---[excerpt begins]---
  The Phony goto Debate

  A primary feature of most goto discussions is a shallow approach
  to the question. The arguer on the "gotos are evil" side usually
  presents a trivial code fragment that uses gotos and then shows
  how easy it is to rewrite the fragment without gotos. This proves
  mainly that it's easy to write trivial code without gotos.
  ---[excerpt ends]---

Indeed it always surprises me how quickly people are willing to
regurgitate the age old argument against the use of goto. In my early
days of programmer, I started as a BASIC spaghetti code programmer
that over used goto's as a matter of course. Then I went to
university where I was told never to use goto (or suffer the wrath of
the TA's grading penalties.) Indeed I trained myself to get out of
using goto's and indeed, I've never come to an algorithm that I
couldn't some implement without gotos.

But then I got a job. On that job I had to really brush up my
assembly skills as that was this language I was to use day-in,
day-out. I have since merged my skills at high level and low level
programming, and when I hear this debate it is enough to make me
cringe. All the so called problems that goto's have are really just
limitations of the coder's skill level, not anything intrinsic about
the use of goto itself.

Some points that I think should be made: Over-use or capricious use
of goto can definately lead to hard to follow and maintain "spaghetti
code". Using high level flow control mechanisms helps the compiler
and helps you see structure in your code. On the other hand, well
placed sparse use of goto is usually clear. Examples:

  * - Using a single goto and single label to exit several levels of
    scope.
  * - Using a goto in the middle of complex construction to short cut
    to the top of a loop.
  * - Starting a highly optimized do { ... } while loop that is best
    initiated by jumping into the center first. (Because your
    compiler is not cooperating.)
  * - Extensions of duff's device.

When you reach a certain level of skill in programming, one
eventually realizes that the issue of writing clean maintainable code
is not function of what specific language features you are using, but
rather how clearly an algorithm is expressed by its implementation
with those language elements. For example, if I am looking at code
for the first time, and I see an isolated label, then I expect to see
a corresponding goto and am not likely to be phased by how the flow
of execution. Are you? On the other hand if I see a ton of nested
if's, while's and so on that use expression side effects and other
implied (as opposed to explicit) constructs as conditionals, I will
tend to have a hard time with it. Exit and start conditions for loops
can be hidden and convoluted just as easy using sanctioned flow
control language elements as it can by over-using goto.

On the plus side to minimizing the use of goto's it can help a
beginner who has been raised on BASIC (like I was) break their bad
habits. The biggest thing that a beginner can expect to learn from
doing this is learning to program at a high level of abstraction that
is different from what they are used to. Getting used to other ways
of programming will help the beginner expand their breadth of
programming paradigms. But as mentioned in "Writing Solid Code" above
you don't want to get into a mode where you are blindly following
rules that have nothing to do with writing clean maintainable code.

Update: I recently looked at the book "Compilers Principles,
Techniques, and Tools". In it, it describes the intermediate
languages that programs are compiled to in which typically all
branches are transformed to goto and if ... goto constructions. The
idea being that optimizations are done after the program has been
transformed to a loopless goto riddled intermediate program. That
seals it for me -- I say use goto whenever it makes sense.
---------------------------------------------------------------------
                         Programming Mail me
---------------------------------------------------------------------
This page hosted by Pair.com.