considered harmful

GoTo (goto, GOTO, GO TO or other case combinations, depending on the programming language) is a statement found in many computer programming languages. It performs a one-way transfer of control to another line of code; in contrast a function call normally returns control. The jumped-to locations are usually identified using labels, though some languages use line numbers. At the machine code level, a goto is a form of branch or jump statement, in some cases combined with a stack adjustment. Many languages support the goto statement, and many do not (see § language support).

The structured program theorem proved that the goto statement is not necessary to write programs that can be expressed as flow charts; some combination of the three programming constructs of sequence, selection/choice, and repetition/iteration are sufficient for any computation that can be performed by a Turing machine, with the caveat that code duplication and additional variables may need to be introduced.

In the past there was considerable debate in academia and industry on the merits of the use of goto statements. Use of goto was formerly common, but since the advent of structured programming in the 1960s and 1970s its use has declined significantly. The primary criticism is that code that uses goto statements is harder to understand than alternative constructions. Goto remains in use in certain common usage patterns, but alternatives are generally used if available. Debates over its (more limited) uses continue in academia and software industry circles.

Usage

goto ''label''

The goto statement is often combined with the if statement to cause a conditional transfer of control.

IF ''condition'' THEN goto ''label''

Programming languages impose different restrictions with respect to the destination of a goto statement. For example, the C programming language does not permit a jump to a label contained within another function, however jumps within a single call chain are possible using the setjmp/longjmp functions.

Criticism

At the pre-ALGOL meeting held in 1959, Heinz Zemanek explicitly cast doubt on the necessity of GOTO statements; at the time no one paid attention to his remark, including Edsger W. Dijkstra, who later became the iconic opponent of GOTO. The 1970s and 1980s saw a decline in the use of GOTO statements in favor of the structured programming paradigm, with goto criticized as leading to unmaintainable spaghetti code. Some programming style coding standards, for example the GNU Pascal Coding Standards, recommend against the use of GOTO statements. The Böhm–Jacopini proof (1966) did not settle the question of whether to adopt structured programming for software development, partly because the construction was more likely to obscure a program than to improve it because its application requires the introduction of additional local variables. It did, however, spark a prominent debate among computer scientists, educators, language designers and application programmers that saw a slow but steady shift away from the formerly ubiquitous use of the GOTO. Probably the most famous criticism of GOTO is a 1968 letter by Edsger Dijkstra called "Go To Statement Considered Harmful". In that letter Dijkstra argued that unrestricted GOTO statements should be abolished from higher-level languages because they complicated the task of analyzing and verifying the correctness of programs (particularly those involving loops). The letter itself sparked a debate, including a "'GOTO Considered Harmful' Considered Harmful" letter sent to ''Communications of the ACM'' (CACM) in March 1987, as well as further replies by other people, including Dijkstra's ''On a Somewhat Disappointing Correspondence''.

An alternative viewpoint is presented in Donald Knuth's ''Structured Programming with go to Statements'', which analyzes many common programming tasks and finds that in some of them GOTO is the optimal language construct to use. In ''The C Programming Language'', Brian Kernighan and Dennis Ritchie warn that goto is "infinitely abusable", but also suggest that it could be used for end-of-function error handlers and for multi-level breaks from loops. These two patterns can be found in numerous subsequent books on C by other authors;
a 2007 introductory textbook notes that the error handling pattern is a way to work around the "lack of built-in exception handling within the C language". Other programmers, including Linux kernel designer and coder Linus Torvalds or software engineer and book author Steve McConnell, also object to Dijkstra's point of view, stating that GOTOs can be a useful language feature, improving program speed, size and code clarity, but only when used in a sensible way by a comparably sensible programmer. According to computer science professor John Regehr, in 2013, there were about 100,000 instances of goto in the Linux kernel code.

Other academics took a more extreme viewpoint and argued that even instructions like break and return from the middle of loops are bad practice as they are not needed in the Böhm–Jacopini result, and thus advocated that loops should have a single exit point. For instance, Bertrand Meyer wrote in his 2009 textbook that instructions like break and continue "are just the old goto in sheep's clothing". A slightly modified form of the Böhm–Jacopini result, however, allows the avoidance of additional variables in structured programming, as long as multi-level breaks from loops are allowed. Because some languages like C don't allow multi-level breaks via their break keyword, some textbooks advise the programmer to use goto in such circumstances. The MISRA C 2004 standard bans goto, continue, as well as multiple return and break statements. The 2012 edition of the MISRA C standard downgraded the prohibition on goto from "required" to "advisory" status; the 2012 edition has an additional, mandatory rule that prohibits only backward, but not forward jumps with goto.

FORTRAN introduced structured programming constructs in 1978, and in successive revisions the relatively loose semantic rules governing the allowable use of goto were tightened; the "extended range" in which a programmer could use a GOTO to enter and leave a still-executing DO loop was removed from the language in 1978, and by 1995 several forms of Fortran GOTO, including the Computed GOTO and the Assigned GOTO, had been deleted. Some widely used modern programming languages such as Java and Python lack the GOTO statement – see language support – though most provide some means of breaking out of a selection, or either breaking out of or moving on to the next step of an iteration. The viewpoint that disturbing the control flow in code is undesirable may be seen in the design of some programming languages, for instance Ada visually emphasizes label definitions using angle brackets.

Entry 17.10 in comp.lang.c FAQ list addresses the issue of GOTO use directly, stating

Common usage patterns

While overall usage of gotos has been declining, there are still situations in some languages where a goto provides the shortest and most straightforward way to express a program's logic (while it is possible to express the same logic without gotos, the equivalent code will be longer and often more difficult to understand). In other languages, there are structured alternatives, notably exceptions and tail calls.

Situations in which goto is often useful include:
* To make the code more readable and easier to follow
* To make smaller programs, and get rid of code duplication
* Implement a finite-state machine, using a state transition table and goto to switch between states (in absence of tail call elimination), particularly in automatically generated C code. For example, goto in the canonical LR parser.
* Implementing multi-level break and continue if not directly supported in the language; this is a common idiom in C. Although Java reserves the goto keyword, it doesn't actually implement it. Instead, Java implements labelled break and labelled continue statements. According to the Java documentation, the use of gotos for multi-level breaks was the most common (90%) use of gotos in C. Java was not the first language to take this approach—forbidding goto, but providing multi-level breaks— the BLISS programming language (more precisely the BLISS-11 version thereof) preceded it in this respect.
* Surrogates for single-level break or continue (retry) statements when the potential introduction of additional loops could incorrectly affect the control flow. This practice has been observed in Netbsd code.
* Error handling (in absence of exceptions), particularly cleanup code such as resource deallocation. C++ offers an alternative to goto statement for this use case, which is : Resource Acquisition Is Initialization (RAII) through using destructors or using try and catch exceptions used in Exception handling. setjmp and longjmp are another alternative, and have the advantage of being able to unwind part of the call stack.
* Popping the stack in, e.g., Algol, PL/I.
* Specialized scripting languages that operate in a linear manner, such as a dialogue system for video games.

These uses are relatively common in C, but much less common in C++ or other languages with higher-level features. However, throwing and catching an exception inside a function can be extraordinarily inefficient in some languages; a prime example is Objective-C, where a goto is a much faster alternative.

Another use of goto statements is to modify poorly factored legacy code, where avoiding a goto would require extensive refactoring or code duplication. For example, given a large function where only certain code is of interest, a goto statement allows one to jump to or from only the relevant code, without otherwise modifying the function. This usage is considered code smell, but finds occasional use.

Alternatives

Structured programming

The modern notion of subroutine was invented by David Wheeler when programming the EDSAC. To implement a call and return on a machine without a subroutine call instruction, he used a special pattern of self-modifying code, known as a Wheeler jump. This resulted in the ability to structure programs using well-nested executions of routines drawn from a library. This would not have been possible using only goto, since the target code, being drawn from the library, would not know where to jump back to.

Later, high-level languages such as Pascal were designed around support for structured programming, which generalized from subroutines (also known as procedures or functions) towards
further control structures such as:
* Loops using while, repeat until or do, and for statements
* switch a.k.a. case statements, a form of multiway branching

These new language mechanisms replaced equivalent flows which previously would have been written using gotos and ifs. Multi-way branching replaces the "computed goto" in which the instruction to jump to is determined dynamically (conditionally).

Under certain conditions it is possible to eliminate local go to statements of legacy programs by replacing them with multilevel loop exit statements.

Exceptions

In practice, a strict adherence to the basic three-structure template of structured programming yields highly nested code, due to inability to exit a structured unit prematurely, and a combinatorial explosion with quite complex program state data to handle all possible conditions.

Two solutions have been generally adopted: a way to exit a structured unit prematurely, and more generally exceptions – in both cases these go ''up'' the structure, returning control to enclosing blocks or functions, but do not jump to arbitrary code locations. These are analogous to the use of a return statement in non-terminal position – not strictly structured, due to early exit, but a mild relaxation of the strictures of structured programming. In C, break and continue allow one to terminate a loop or continue to the next iteration, without requiring an extra while or if statement. In some languages multi-level breaks are also possible. For handling exceptional situations, specialized exception handling constructs were added, such as try/catch/finally in Java.

The throw-catch exception handling mechanisms can also be easily abused to create non-transparent control structures, just like goto can be abused.

Tail calls

In a paper delivered to the ACM conference in Seattle in 1977, Guy L. Steele summarized the debate over the GOTO and structured programming, and observed that procedure calls in the tail position of a procedure can be most optimally treated as a direct transfer of control to the called procedure, typically eliminating unnecessary stack manipulation operations. Since such "tail calls" are very common in Lisp, a language where procedure calls are ubiquitous, this form of optimization considerably reduces the cost of a procedure call compared to the GOTO used in other languages. Steele argued that poorly implemented procedure calls had led to an artificial perception that the GOTO was cheap compared to the procedure call. Steele further argued that "in general procedure calls may be usefully thought of as GOTO statements which also pass parameters, and can be uniformly coded as machine code JUMP instructions", with the machine code stack manipulation instructions "considered an optimization (rather than vice versa!)". Steele cited evidence that well optimized numerical algorithms in Lisp could execute faster than code produced by then-available commercial Fortran compilers because the cost of a procedure call in Lisp was much lower. In Scheme, a Lisp dialect developed by Steele with Gerald Jay Sussman, tail call optimization is mandatory.

Although Steele's paper did not introduce much that was new to computer science, at least as it was practised at MIT, it brought to light the scope for procedure call optimization, which made the modularity-promoting qualities of procedures into a more credible alternative to the then-common coding habits of large monolithic procedures with complex internal control structures and extensive state data. In particular, the tail call optimizations discussed by Steele turned the procedure into a credible way of implementing iteration through single tail recursion (tail recursion calling the same function). Further, tail call optimization allows mutual recursion of unbounded depth, assuming tail calls – this allows transfer of control, as in finite state machines, which otherwise is generally accomplished with goto statements.

Coroutines

Coroutines are a more radical relaxation of structured programming, allowing not only multiple exit points (as in returns in non-tail position), but also multiple entry points, similar to goto statements. Coroutines are more restricted than goto, as they can only ''resume'' a currently running coroutine at specified points – continuing after a yield – rather than jumping to an arbitrary point in the code. A limited form of coroutines are generators, which are sufficient for some purposes. Even more limited are closures – subroutines which maintain state (via static variables), but not execution position. A combination of state variables and structured control, notably an overall switch statement, can allow a subroutine to resume execution at an arbitrary point on subsequent calls, and is a structured alternative to goto statements in the absence of coroutines; this is a common idiom in C, for example.

Continuations

A continuation is similar to a GOTO in that it transfers control from an arbitrary point in the program to a previously marked point. A continuation is more flexible than GOTO in those languages that support it, because it can transfer control out of the current function, something that a GOTO cannot do in most structured programming languages. In those language implementations that maintain stack frames for storage of local variables and function arguments, executing a continuation involves adjusting the program's call stack in addition to a jump. The longjmp function of the C programming language is an example of an escape continuation that may be used to escape the current context to a surrounding one. The Common Lisp GO operator also has this stack unwinding property, despite the construct being lexically scoped, as the label to be jumped to can be referenced from a closure.

In Scheme, continuations can even move control from an outer context to an inner one if desired. This almost limitless control over what code is executed next makes complex control structures such as coroutines and cooperative multitasking relatively easy to write.

Message passing

In non-procedural paradigms, goto is less relevant or completely absent. One of the main alternatives is message passing, which is of particular importance in concurrent computing