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. Many languages support the goto statement, and many do not; see language support for discussion.
The structured program theorem proved that the goto statement is not necessary to write programs; 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.
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.
- 1 Usage
- 2 Criticism and decline
- 3 Common usage patterns of Goto
- 4 Alternatives
- 5 Variations
- 6 Language support
- 7 See also
- 8 Notes
- 9 References
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 and decline
Although at the pre-ALGOL meeting held in 1959, Heinz Zemanek explicitly threw doubts on the necessity of GOTO statements, at the time no one paid attention to his remark, including Edsger Dijkstra, who would later become 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" (see below). Some programming style coding standards, for example the Gnu Pascal Coding Standards, recommend against the use of GOTO statements. The Böhm-Jacopini proof 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. It has, however, sparked 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. Some programmers, such as 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 clearness, but only when used in a sensible way by a comparably sensible programmer.
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 of forms of Fortran GOTO, including the Computed GOTO and the Assigned GOTO, had been deleted from the language. 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
Programming style, like writing style, is somewhat of an art and cannot be codified by inflexible rules, although discussions about style often seem to center exclusively around such rules. In the case of the goto statement, it has long been observed that unfettered use of goto's quickly leads to unmaintainable spaghetti code. However, a simple, unthinking ban on the goto statement does not necessarily lead immediately to beautiful programming: an unstructured programmer is just as capable of constructing a Byzantine tangle without using any goto's (perhaps substituting oddly-nested loops and Boolean control variables, instead). Many programmers adopt a moderate stance: goto's are usually to be avoided, but are acceptable in a few well-constrained situations, if necessary: as multi-level break statements, to coalesce common actions inside a switch statement, or to centralize cleanup tasks in a function with several error returns. (...) Blindly avoiding certain constructs or following rules without understanding them can lead to just as many problems as the rules were supposed to avert. Furthermore, many opinions on programming style are just that: opinions. They may be strongly argued and strongly felt, they may be backed up by solid-seeming evidence and arguments, but the opposing opinions may be just as strongly felt, supported, and argued. It's usually futile to get dragged into "style wars", because on certain issues, opponents can never seem to agree, or agree to disagree, or stop arguing.
Common usage patterns of Goto
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 program's logic (while it's 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 Linux: Using goto In Kernel Code
- To make smaller programs, and get rid of code duplication Linux: Using goto In Kernel Code
- Parsers (that may be one of the reason why many compilers for different languages is written in C code),
- multi-level breaks (if not supported and no exceptions),
- transitions in finite-state machines (in absence of tail call elimination),
- error handling (in absence of exceptions), particularly cleanup code such as resource deallocation.
These uses are relatively common in C, but much less common in C++ or other languages with higher-level features.
An important use of goto is in parsers, which are often implemented via a finite state machine, using a state transition table and goto to switch between states, particularly in automatically generated C code; see for example goto in the canonical LR parser.
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 poor code smell, but finds occasional use.
In classical structured programming, three basic structures are used: sequence, repetition, and selection. Sequence is the execution of one program unit following another; repetition is the repeated execution of the same program unit until a desired program state is reached; and selection is the executing of one and only one of a fixed set of possible alternative program units depending on the program state. Here typically the "program unit" is a compound statement constructed in turn using the three basic structures.
Although these three control structures can all be hand-coded using
ifs, the desire for clarity and efficient optimization led to the introduction and refinement of supporting structures such as (in Pascal) procedure and function blocks,
repeat until, and
for statements, and
case statements (a form of multiway branching, replacing computed goto).
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,
continue allow one to terminate a loop or continue to the next iteration, without requiring an extra
if statement. In some languages multi-level breaks are also possible. For handling exceptional situations, specialized exception handling constructs were added, such as
finally in Java.
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 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.
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.
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, interprocess communication, and object oriented programming. In these cases, the individual components do not have arbitrary transfer of control, but the overall control may be scheduled in complex ways, such as via preemption. The influential languages Simula and Smalltalk were among the first to introduce the concepts of messages and objects. By encapsulating state data, object-oriented programming reduced software complexity to interactions (messages) between objects.
There are a number of different language constructs under the class of goto statements.
GOTO (originally Fortran terminology) jumps to one of several labels based on the value of an expression. The
ON ... GOTO statement in BASIC supports the computed GOTO and is useful for case-by-case branching, as in C's switch statement. 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).
Originally found in Fortran, this variant transfers control to a statement label which is stored in (assigned to) a variable.
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. This C extension is sometimes referred to as a Computed goto, but it has the semantics of an assigned goto.
The 1985 ANSI COBOL standard had the ALTER verb which could be used to change the destination of an existing GO TO, which had to be in a paragraph by itself. The feature, which allowed polymorphism, was frequently condemned and seldom used.
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.
PL/I label variables
PL/I has the data type LABEL, which can be used to implement both the "assigned goto" and the "computed goto." PL/I allows branches out of the current block. A calling procedure can pass a label as an argument to a called procedure which can then exit with a branch.
/* This implements the equivalent of */ /* the assigned goto */ declare where label; where = somewhere; goto where; ... somewhere: /* statement */ ; ...
/* This implements the equivalent of */ /* the computed goto */ declare where (5) label; declare inx fixed; where(1) = abc; where(2) = xyz; ... goto where(inx); ... abc: /* statement */ ; ... xyz: /* statement */ ; ...
Many languages support the goto statement, and many do not. In Java, goto is a reserved word, but is unusable. Python does not have support for goto, other than in the joke module goto. In PHP there was no native support for goto until version 5.3 (libraries were available to emulate its functionality).
C has goto, and it is commonly used in various idioms, as discussed above.
Functional programming languages such as Scheme generally do not have goto, instead using continuations.
- Control flow
- Switch statement – a multiway branch (or conditional goto)
- Unstructured programming
- Considered harmful
- Munroe, Randall. "XKCD - Goto".
- C Standard section 184.108.40.206 The goto statement
- Edsger Dijkstra (March 1968). "Go To Statement Considered Harmful". Communications of the ACM 11 (3): 147–148. doi:10.1145/362929.362947.
- Frank Rubin (March 1987). ""GOTO Considered Harmful" Considered Harmful" (PDF). Communications of the ACM 30 (3): 195–196. doi:10.1145/214748.315722.
- Dijkstra, Edsger W. On a Somewhat Disappointing Correspondence (EWD-1009). E.W. Dijkstra Archive. Center for American History, University of Texas at Austin. (original; transcription) (May, 1987)
- Donald Knuth (1974). "Structured Programming with go to Statements". Computing Surveys 6 (4): 261–301. doi:10.1145/356635.356640.
- ANSI X3.9-1978. American National Standard – Programming Language FORTRAN. American National Standards Institute. Also known as ISO 1539-1980, informally known as FORTRAN 77
- ISO/IEC 1539-1:1997. Information technology – Programming languages – Fortran – Part 1: Base language. Informally known as Fortran 95. There are a further two parts to this standard. Part 1 has been formally adopted by ANSI.
- John Barnes (2006-06-30). Programming in Ada 2005. Addison Wesley. p. 114–115. ISBN 0-321-34078-7.
- Good uses of goto, Simon Cozens
- When To Use Goto When Programming in C, Alex Allain
- Guy Lewis Steele, Jr.. "Debunking the 'Expensive Procedure Call' Myth, or, Procedure Call Implementations Considered Harmful, or, Lambda: The Ultimate GOTO". MIT AI Lab. AI Lab Memo AIM-443. October 1977.
- R5RS Sec. 3.5, Richard Kelsey, William Clinger, Jonathan Rees et al. (August 1998). "Revised5 Report on the Algorithmic Language Scheme". Higher-Order and Symbolic Computation 11 (1): 7–105. doi:10.1023/A:1010051815785.
- Revised5 Report on the Algorithmic Language Scheme (R5RS), section 6.4, standard procedures: call-with-current-continuation
- "Microsoft QuickBASIC: ON...GOSUB, ON...GOTO Statements QuickSCREEN.". Microsoft. 1988. Retrieved 2008-07-03.
- Computed goto, IBM XL C/C++ compiler
- HP COBOL II/XL Reference Manual, "The ALTER statement is an obsolete feature of the 1985 ANSI COBOL standard."
- Van Tassel, Dennie (July 8, 2004.). "History of Labels in Programming Languages". Retrieved 4 January 2011.
- Goto, from the perl.syn (Perl syntax) manual
- "GOTO for Java". steike. Posted July 6, 2009. Retrieved April 28, 2012.
- Sexton, Alex. "The Summer of Goto | Official Home of Goto.js". Retrieved April 28, 2012.
- Hindle, Richie (April 1, 2004). "goto for Python". Entrian Solutions. Hertford, UK: Entrian Solutions Ltd. Retrieved April 28, 2012. "The 'goto' module was an April Fool's joke, published on 1st April 2004. Yes, it works, but it's a joke nevertheless. Please don't use it in real code!"
- "The Java Language Specification, Third Edition". "The keywords const and goto are reserved, even though they are not currently used. This may allow a Java compiler to produce better error messages if these C++ keywords incorrectly appear in programs."
- "The Java Language Specification, Third Edition". "Unlike C and C++, the Java programming language has no goto statement; identifier statement labels are used with break (§14.15) or continue (§14.16) statements appearing anywhere within the labeled statement."