Paul Hsieh's Goto Page

GOTO

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.

This page hosted by Pair.com.