This is an open access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, reproduction and adaptation in any medium and for any purpose provided that it is properly attributed. For attribution, the original author(s), title, publication source (PeerJ PrePrints) and either DOI or URL of the article must be cited.
It is nearly 50 years since Dijkstra argued that goto obscures the flow of control in program execution and urged programmers to abandon the goto statement. While past research has shown that goto is still in use, little is known about whether goto is used in the unrestricted manner that Dijkstra feared, and if it is ‘harmful’ enough to be a part of a post-release bug. We, therefore, conduct a two part empirical study - (1) qualitatively analyze a statistically representative sample of 384 files from a population of almost 2 million C programming language files collected from over 11K Github repositories and find that developers use goto in C files for error handling (80.21 ± 5%) and cleaning up resources at the end of a procedure (40.36 ± 5%); and (2) quantitatively analyze the commit history from the release branches of six OSS projects and find that no goto statement was removed/modified in the post-release phase of four of the six projects. We conclude that developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared, thus suggesting that goto does not appear to be harmful in practice.
This report contains our entire work. Parts of this paper will be submitted to IEEE SW or a similar journal with a high readership of software developers.
A fun article. It would be nice, however, to see a discussion (even brief) of the recent "goto fail" security problem in Apple's SSL implementation. Are the times that goto caused an error significant enough to warrant its banishment?
It seems to me that Dijkstra's fears have had two salutary effects on the use of goto statements:
1. The development of various other control structure abstractions that are safer and often easier to understand than gotos would be. This allowed a great reduction in their use since the days of FORTRAN and BASIC.
2. The cultural effect of actively discouraging goto statements, which has served to prevent the worst abuses and perhaps relegated gotos to only the few applications that were found in this analysis. This is, of course, aided by the control constructs added to remove/reduce the need to use gotos in code in the first place.