Why is goto a bad programming practice?

Why is goto considered harmful?
I have been thinking about this for some time but can't find any plausible answer. What is the reason, exactly, that a goto statement is considered harmful? Why is it bad programming practice? I have been trained to write programs without goto and also avoid using it, but what is the thing actually hat makes it bad programming anyway? The only reason I have found it to be considered bad programming practice is due to a paper by Djikstra, but I haven't been able to get the paper. Does anyone have a convincing answer?

It can easily lead to "spaghetti code". In untrained hands, goto can be used to create a tangled web of code where code can be redirected to anywhere else in the code without consideration for proper constructs like loops and conditional blocks.

eg. a goto statement could redirect the code to a line in the middle of a while or for loop.

It's not that it's evil per se. But unless you're programming in an ancient, low-level (by today's standards) language like early BASICs and machine code, you have more abstract control structures available than are easier to use, require less code and are more easily followed by the reader. Programmers (except perhaps those constantly working in enviroments that require otherwise) don't think in terms of jumps. A conditional gotos that emulates a for loop "works", and is indeed equivalent from a purely theoretical viewpoint, but it's less obvious to the reader what the code actually does (well, it jumps to X if some condition is met, but that's not what you want to know when you read it - you want to know what it's counting from n to m). This gets worse as control flow gets more sophisticated. An iterator-based loop with a conditional break; and continue; contining a few if statements can easily have more than a dozen gotos, and you have to dig through all of them, make sure the translation from "do this for every number i in n...m" to "count and jump around like this" is correct, etc.

And then there's the abuse potential: Some bat**** insane guy can go and jump in the middle of your code, so strictly speaking you can never assume the line before actually executed. Adding extra checks won't help though, as they too require additional lines that may be jumped over - not to mention that you shouldn't have to concern yourself with such madness. And in fact, many (in particular beginners who don't know better - sign me up for this) lack the discipline not to create this kind of mess where everyone jumps everywhere and mentally tracing execution becomes very hard (if not practically impossible). Those who do have the discipline would (in 99.99% of all cases) only recreate existing control structures, so they just use those. Unless, of course, the language in use lacks them.

Note that all this implies thta goto IS okay when you have no high-level control structure that can be used to solve this problem better. E.g. cleanup in C (which has no exception handling and no RAII) - put cleanup + return in the end. If an error occurs, jump there, and if no error occurs, you get there as well. Prevents deeeeeep nesting of conditionals.

It seems that goto is considered harmful only if I use it to create elaborate loops and sub routine calls such as for, while loops and functions. In fact, I have read that after Djikstra published his paper, some other prominent people working in the field of computers at that time published their own counter arguments to Djikstra, which made Djikstra publish further counterarguments to those counterarguments. So it seems, the practice of considering goto a bad habit was itself debatable. So goto can lead to spaghetti code. Considering this true, what if I just use goto with some if then conditions to skip just few lines or blocks of code, never nest goto, never use goto to enter or leave a block and avoid using goto to move back in a program. Would this be a bad practice then?

I always thought it has something to do with the design of compilers which makes goto a bad practice, but now I'm beginning to think I was wrong

This was published in the late 60's. If you want to base rules of modern computers on 40 year old arguments (yes I know the counter arguments were later), a lot has changed. Computers had kilobytes of memory and megabytes of hard drive, kilohertz processors and bandwidth referred to how fast you could read off of disks, not from anywhere in the world.


Behind the scenes an if statement is just a true check and a goto. The same is true with for loops, while loops, function calls, and any other advanced structure you might use, compile down to goto statements (or jumps and page jumps if you want to get technical). Anything you might be saving by doing a goto inside an if statement is actually just costing you two gotos. Instead of using an "If (condition) Goto blah End If do_stuff() declare blah" Try using "If (Not Condition) do)stuff() End If"


Er.... kinda, but it's not for the compiler's sake it's for yours. By avoiding goto's in favor of more complex structures that use goto's the compiler has a better idea what is going on. It can understand the flow of the structures, and do extra checks like making sure you have the variables declared (or hasn't been finalized) before using them, or making sure your call stack stays accurate and appropriate variables get passed back. And that variables leave scope when they're no longer used in the loop. By using these structures you're gaining all of that logic as well, and the compiler now has the ability to check for these things instead of only finding out at runtime.

-MBirchmeier

So scarce and controlled use of goto should be legalized (in the academic sector as well I mean)? What do you think?

I think you either did not understand or did not read what I posted. And that if you did not understand it and you're truly interested in learning you should be asking questions. Rather than simply re-asserting your statement. If you didn't read it or just have no interest in learning then I'm guessing we're done here anyway.

-MBirchmeier

No.

In nearly 2 decades of programming professionally I have never used a GOTO, nor come across a use of GOTO that could not be avoided by better design.

Learn assembly language. Write a program in assembly language. Debug your own bugs in assembly language.

That's the only way to truly appreciate the horror of goto: using a language with ONLY GOTO.

^^^
Actually, Knuth proved that it is perfectly possible to write good code with GOTO and in some problem domains, the alternatives are more complicated .

I use goto sparingly in my own C code, mostly for error handling [1]. In fact, it is a pet theory of mine that if there aren't enough goto statements in a non-trivial C program, maybe the programmer isn't doing enough error checking or leaving resources open.

-----------------
[1] Code that I write usually run as daemons for very long periods of time. Using exit() is often not an option and resource deallocation is very important. Incidentally, any decent OS (Windows, Linux, *BSD) code or long running daemon code (such as Apache, various mail servers etc.) contains goto as well. A lot of the Windows C API examples contain goto as well. Here's Linus Torvalds' word on the subject

What it really comes down to is that GOTO is a very low-level construct, and a very general and powerful one, but one which lends itself to abuse. The construct itself isn't the problem, for the most part; it is the use to which it can be put. This was a much bigger issue in the past, because the importance of being able to read existing code wasn't fully appreciated, but the debate is one which is for the most part long over.

In the end, the main argument against GOTO (and it's more abstract cousin, continuations) is that there are a large number of less general, but more structured, constructs which can replace it, in a way that makes reading the resulting code generally easier. It is a very rare case when GOTO is more readable than the equivalent in other forms such as for() or while() loops, recursive calls, or simply decomposing the problem further. Such cases do occur, but I doubt most C programmers see more than one or two such cases in a career, and it is even rarer in higher-level languages.