Evil GoTo

[Labdabeta]

A friend of mine recently asked me to help debug some code. I looked through it and it was riddled all over with goto statements. I know why he uses them (he used to program mainly in assembly and batch) and I tried to explain why he should try to refrain from using goto statements. The problem was that he thinks that I just have a personal vendetta against goto statements, and does not believe that they are harmful. Can anybody give me some concrete, indisputable reasons why the goto statement is evil?

[thines01]

http://david.tribble.com/text/goto.html

[mike_2000_17]

Once you understand the idea that the purpose of a programming language is to act as an interface between a human being and a computer, then it becomes pretty clear why goto statements are bad. A guy that is trained to write assembly code might have a brain that is closer to that of a computer than a human being.

Looking at the standard, except for the two small sections that explain what goto and label are, and the uses of goto to explain what under flow control constructs do, all the mentions of goto relate to the types of ill-formed code they can cause. This involves jumping across code that creates objects and jumping in or out of try-catch blocks. Another, more important issue is the non-linearity that they generally introduce in the code. A for-loop is easy to explain, run the statements from start to finish and do it again for X number of times. Code that is expressed as a number of loops and conditional statements is fairly easy to follow logically. A spaghetti code of goto statements, or careless jumping around is much harder to follow and thus much more error-prone (forgetting to handle a particular condition, losing track of values of variables, and so on).

It is true that a good programmer, especially one used to working with assembly code, will be able to mostly avoid those pitfalls when writing the code, but that is a very weak defense of gotos for one reason: no man is an island. Another programmer or yourself revising the code at a later time will generally have a much harder time making good sense of code if it involves many goto statements. You also lose the benefits of indentation as a means to help you understand the code at the glimpse of an eye. Revisiting code whether it is for improvements, extensions, or debugging, is one of those dangerous operations that can easily introduce new bugs by slightly misunderstanding the way the code works and making an erroneous addition or modification. You need all the help you can get to make the code as understandable as possible, especially the logic of it.

Your friend might say something like "but these are not real arguments", because some people tend to somehow disregard issues of maintainability and bad, error-generating coding practices. Then tell him to wake up and smell the roses, it's been half a century of computer science research working on these issues, because these things matter!

In C++, the only reasonable application of goto is to jump out of a nested loop. And then there are those very few examples of really cool uses of goto statements which would be really hard without them, but these are very few and far apart, you would rarely ever see them in real code.

We tell programmers that "goto is evil" mostly as a way to avoid them the pain of going down a path that fosters bad coding practices and will inevitably cause them a world of pain in debugging time and maintenance issues. If you stay away from goto statements, you are likely to develop alternative constructs that are generally just as good (code-wise) and are much better from a coding practices point of view.

In reality nothing is really evil, especially if it was accepted and retained in the standard by the standard committee. Somethings you just ought to avoid as much as possible, that is, if you want to keep your sanity.

[Labdabeta]

Thank you very much!