For other uses see Goto (disambiguation).
GOTO is a statement found in many computer programming languages. It is a combination of the English words go and to. When executed it causes an unconditional transfer of control (a "jump") to another statement. The jumped-to statement is specified using some kind of label, which may be an identifier or a line number depending on the language. At the machine code level a
goto is a form of branch or jump statement.
In some languages,
goto functionality may be present without explicit use of the keyword
goto, such as where a
continue keyword may be followed by an identifier denoting a label. The SNOBOL programming language supports a form of statement suffix which causes an unconditional transfer of control after the statement has finished executing.
While GOTO statements are found in most high-level languages, there are a few high-level languages that do not support them. For instance, Java (where
goto is a reserved word but does not presently serve any function).
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 the jump location of a
goto statement. For example, in the C programming language it is not allowed to jump to a label contained within another function. The setjmp/longjmp functions provide support for non-local gotos.
The GOTO statement has been the target of much continued criticism and debate, with the primary negative claim being that use of GOTO results in unreadable and generally unmaintainable "spaghetti code". As structured programming became more popular in the 1960s and 1970s, many computer scientists came to the conclusion that programs should always use so-called 'structured' flow-control commands such as loops and if-then-else statements in place of GOTO. Even today some programming style coding standards forbid the use of GOTO statements using similar rationales. In defense of GOTO statements, others have noted that the restrained use of GOTO does not necessarily lead to poor quality code, and also argue that there are some tasks that cannot be straightforwardly accomplished in many programming languages without the use of one or more GOTO statements, such as implementing finite state machines, breaking out of nested loops and exception handling.
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). 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.
This criticism had an effect on the design of some programming languages. Although the designers of the Ada language in the late 1970s were aware of the criticisms of GOTO, the statement was still included in the language, mainly to support automatically generated code where the
goto might prove indispensable. However, the labels used as the destination of a goto statement take the unusual form of an identifier enclosed in double angle brackets (e.g.
<) and this syntax is not used anywhere else in the language. This makes it easy to check a program for the existence of goto destinations. The goto statement itself takes the simple form
There are a number of different language constructs which can be described as forms of goto:
Many languages, such as C and Java, provide related control flow statements, like
continue, which are effectively restricted formsof the goto statement. Their effect is an unconditional jump, but they can only be used to jump to a point after the end of a loop block - either to continue a loop at the next iteration (continue), or to end the loop (break).
The switch statement in C, C++ and Java effectively performs a multi-way goto where the destination is selected by the value of an expression. In some other languages the switch (or case) statement does not behave in precisely this way (it does not have "fall-through" behaviour).
GOTO (originally Fortran terminology) either jumps to one of several labels based on the value of an expression, or jumps to a label that has been stored in a variable. The
ON ... GOTO statement in BASIC supports the first kind of computed GOTO and is useful for case-by-case branching, as in C's switch statement. Some C compilers (e.g., gcc) support
goto with a label variable using the label value operator. The label value operator
&& returns the address of its operand, which must be a label defined in the current function or a containing function. The value is a constant of type
void * and should be used only in a computed goto statement. The feature is an extension to C and C++, implemented to facilitate porting programs developed with GNU C.
Some variants of BASIC support a computed GOTO that can be any line number, not just one from a list. For example, one could write
GOTO i*1000 to jump to the line numbered 1000 times the value of a variable i (which might represent a selected menu option, for example).
A continuation is similar to a computed GOTO in that it transfers control from an arbitrary point in the program to a previously marked point. A continuation can be more flexible than GOTO in some languages because it can leave the current function, something that a GOTO cannot do in most languages. Executing a continuation usually involves some adjustment of 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 Perl, there is a variant of the
goto statement that is not a traditional GOTO statement at all. It takes a function name and transfers control by effectively substituting one function call for another (a tail call): the new function will not return to the GOTO, but instead to the place from which the original function was called. Early versions of COBOL had the ALTER verb to accomplish this.