For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. — Edsger W. Dijkstra
One of the classics of computer science is Edsger Dijkstra’s “Go To Statement Considered Harmful“, written in 1968. This missive argued that the GOTO statement (present in several languages at the time, including Fortran) was too primitive for high-level programming languages, and should be avoided.
Most people now agree with this, although some even today think that GOTOs are fine under some circumstances. They are present in C and C++, and are apparently used extensively in the Linux kernel. A recent study of C code in GitHub concluded that GOTO use is not that bad and is mainly used for error-handling and cleanup tasks, for situations where there are no better alternatives in C. However, C being a low-level language, we should not expect much from it. For modern Fortran users however, there are better ways to do these things. For example, unlike in C, breaking out of multiple loops is possible without GOTOs by using named DO loops with an EXIT statement like so:
a_loop : do a=1,n b_loop: do b=1,m !do some stuff ... if (done) exit a_loop ! break out of the outer loop !... end do b_loop end do a_loop
In old-school Fortran (or C) this would be something like this:
do a=1,n do b=1,m ! do some stuff ... if (done) goto 10 ! break out of the outer loop ! ... end do end do 10 continue
Of course, these two simple examples are both functionally equivalent, but the first one uses a much more structured approach. It’s also a lot easier to follow what is going on. Once a line number is declared, there’s nothing to stop a GOTO statement from anywhere in the code from jumping there (see spaghetti code). In my view, it’s best to avoid this possibility entirely. In modern Fortran, DO loops (with CYCLE and EXIT), SELECT CASE statements, and other language constructs have obviated the need for GOTO for quite some time. Fortran 2008 added the BLOCK construct which was probably the final nail in the GOTO coffin, since it allows for the most common use cases (exception handing and cleanup) to be easily done without GOTOs. For example, in this code snippet, the main algorithm is contained within a BLOCK, and the exception handling code is outside:
main: block ! do some stuff ... if (error) exit main ! if there is a problem anywhere in this block, ! then exit to the exception handling code. ! ... return ! if everything is OK, then return end block main ! exception handling code here
The cleanup case is similar (which is code that is always called):
main: block ! do some stuff ... if (need_to_cleanup) exit main ! for cleanup ! ... end block main ! cleanup code here
I don’t believe any of the new programming languages that have cropped up in the past couple of decades has included a GOTO statement (although someone did create a goto statement for Python as an April Fool’s joke in 2004). Of course, the presence of GOTO’s doesn’t mean the programmer is bad or that the code isn’t going to work well. There is a ton of legacy Fortran 77 code out there that is rock solid, but unfortunately littered with GOTOs. An example is the DIVA integrator from the JPL MATH77 library (the screenshot above is from this code). First written in 1987, it is code of the highest quality, and has been used for decades in many spacecraft applications. However, it is also spaghetti code of the highest order, and seems like it would be unimaginably hard to maintain or modify at this point.
- E. W. Dijkstra, “Go To Statement Considered Harmful“, Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148 [online version here]
- E. A. Meyer, “Considered Harmful” Essays Considered Harmful, December 28, 2002.
- M. Nagappan, et. al, “An Empirical Study of Goto in C Code from GitHub Repositories“, Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering, Pages 404-414
- Using GOTO in Linux Kernel Code, January 13, 2003,