GOTO Statement: A Balanced View Nils Rohr University of Kaiserslautern, Embedded Systems Group [email protected] Abstract The topic of this paper is a discussion, which exists for roughly 40 years. The discussion whether the use of the Goto Statement in higher Programming languages is dangerous for the quality of a good Code. This Paper looks at the arguments of many Scientist that justify the existence of the Goto and those that speak for its removal from higher programming languages. With the length of time, this topic is discussed it its hard to keep an overview of all the arguments discussed. This paper tries to accomplish this and to provide a conclusion by looking at old arguments from the standpoint of a Bachelor student in the year 2018. 1 Introduction Since the first programming languages have been invented, the style of programming became a huge topic. The goal of a programming language was to allow the programmer to write algorithms that are humanly readable without putting much energy into understanding what the program should do. A good style of programming has many advantages. For once there is the advantage that the programmer can see mistakes easier and by that avoid and fix mistakes easier and faster. A good and consistent style of programming allows others to read the programs better and by that understand it quicker. This allows easier cooperation when working on a project as a team instead of alone. And even when working alone, a good readable program allows better expandability of the program as well as easier reuse of code to for a project. Taking all that into account it seems understandable, that task of improving the style of programming has a high priority. But that is not the only priority that programming language developers have. Every programming languages have its own goals to fulfill. For some that are high compatibility with many systems, like Java, or Python. For others, it allows the computation to be as fast as possible. As well as many other goals that are out there. Given all of that, it seems easy to reason that the syntax of programming languages is evolving constantly, allowing different styles of coding which seems better for the intended purpose of the programming lan- guages and preventing other styles of coding that don’t fit. One way for programming languages to prevent the possibility of writing bad coding styles is remov- ing constructs that have been shown to lead to unstructured and hardly readable code. One of those constructs is the GOTO construct, which is shown by many to have the possibility to lead to hardly un- derstandable code if used in the wrong way. Removing this construct from programming languages has been in discussion since 1968 when Dijkstra’s famous article ”Go To Statement Considered Harmful” 2 was published, which argued that the use of GOTO in the wrong way, would lead to code that was hard to understand. On the other hand from the standpoint of people using the GOTO statement, it seemed that there were cases where the GOTO statement could hardly be avoided. That controversy opened up a big wave of discussions with arguments against the existence of GOTO but also for the existence of it. This had the result that the use of GOTOs was mostly condemned by the big majority of programmers but it could still be found in a number of cases. Since the first discussion, big developments in program- ming happened and many new styles and programming constructs evolved. With that, the old arguments might be not valid anymore and new arguments for and against the GOTO statement might have come up. In this paper, I’m going to pick up the old discussion and see if it is still good to keep the GOTO statement, or if it is better to remove it from higher programming languages completely. I plan on structuring the paper the following way. First I will state the related work, in the form of discussions that have been made over the years, with different viewpoints and angle to look at the topic. After that, I’m going to see if these arguments are still applicable to the currently used programming languages. This part will hold the actual discussion and help to form a conclusion about the topic. The conclusion will be the last part going over the arguments and seeing if GOTO should be removed or not. The last part of this paper will be a list of all the papers I used for my discussion. 2 Related Work 2.1 Edsger W. Dijkstra [2] The first time the discussion about eliminating the GOTO statement from higher programming languages came up with the famous article, written by Dijkstra, with the title ”Go To Statement Considered Harm- ful”, in the year 1968. In his article, Dijkstra presented a way to measure in which way the GOTO can have an effect on the correspondence between the code in readable order, and the order in which the code is executed by the machine. Dijkstra did this by defining the ”textual index”, which manly can be seen as the current line of code if every line would be one command in a timestep. Increasing the index means going to the next line in the code. Given that index, he looked in which way the execution of the code can be characterized by it. He quickly came to the conclusion, by looking at procedures ”that a single textual index is [not] suf- ficient”, but it needs to be added, ”which call of the procedure [is referred to]”. Further, when adding repetition clauses he needed to change the textual index to a ”dynamic textual index”, which adds an ordinal number which increases by the number of repetition. With such a way many programs can be characterized fairly easy. Dijkstra stated that ”our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed”. He concluded because of that, that ”we should do...our utmost best to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program...and the process...as trivial as possible” All this can be fairly easily fulfilled when using the stated constructs. But when unrestrained GOTO state- 3 ments are included that changes. He states that when trying to characterize such a code ”one can...still describe the progress uniquely by [counting] the number of actions performed since program start”, but that ”such a coordinate...is utterly unhelpful” and complicated for a human to use. Dijkstra stated that the GOTO statement itself would be to ”primitive” and ”too much of an invitation to make a mess in one’s program” 2.2 Donald Knuth [4] Donald Knuth can be seen as one of the pioneers of the internet. Especially his work ”The Art of Pro- gramming”, speaks much about how to program in ways that the makes the code easier to read and that increases the over all quality of the code. When the discussion about the GOTO arose one could almost guess that Knuth will get in on it. He did by his paper ”Structured Programming with go to Statements” in the year 1974. Knuth wrote a discussion about on the one hand how the GOTO statement can be avoided but on the other hand in which way it can be used to increase speed and the quality of the pro- gram. In the first part of his paper, Knuth focused on how the GOTO statement could be avoided, by show- ing example uses for the GOTO and removing it by different tactics, or by naming new structures that were in the discussion but not fully used by all programming languages. His goal was to remove the GOTO statement from the code, without decreasing the efficiency of the code. In many of his named cases, he even managed to increase the speed by removing the GOTO. But in some of his cases, he had to pay the cost of decreasing the readability. In the second part, he showed ways that a GOTO statement could help increase the speed of the code, by giving code examples without GOTO and adding a GOTO into it to increase its efficiency. Often he didn’t stop there but managed to remove the GOTO by using other constructs, he talked about. His conclusion was that even if GOTO could be used in bad ways there were still cases in which the use GOTO could lead to well-structured programs, especially with better constructs missing in the pro- gramming languages at his time to replace the GOTO in a well-structured way. For the problem with efficiency Knuth stated that most of the time ”we should...keep efficiency con- siderations in the background when we formulate programs”. In the case, that efficiency is important most of the time we only need to improve a small fraction of the code. He didn’t go into detail about whether that should be done with the GOTO statement or not, but he stated that we should use a ”well structured program” as a basis and increase it with well-understood transformations that can be applied mechanically. He also stated that although GOTO could be used in a meaningful way ”[he] probably would never use it, if the...constructs suggested in [his] paper were present.” Since the time Knuth’s paper has been written many new programming constructs were invented, that could help to remove the GOTO constructs from the code.