GOTO Statement: a Balanced View

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 ﬁrst 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 ﬁx 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 fulﬁll. 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 languages and preventing other styles of coding that don’t ﬁt.

One way for programming languages to prevent the possibility of writing bad coding styles is removing 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 understandable 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 ﬁrst discussion, big developments in programming 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 ﬁrst 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 deﬁning 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- ﬁcient”, 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 fulﬁlled 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 program.

In the ﬁrst part of his paper, Knuth focused on how the GOTO statement could be avoided, by showing 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 efﬁciency 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 efﬁciency. 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 programming 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. Some of those were implemented in ways that were not even talked about by Knuth in this paper. 4

In the further sections of this paper, I will try to take some code examples of Knuth’s paper and apply some of these constructs onto them.

2.3 Martin E. Hopkins [3] As well as Knuth, Martin E. Hopkins did take a stand on the GOTO controversy in 1972 with his paper ”A case for the GOTO” in which Martin talked about positive arguments for the use of the GOTO statement, which seemed to ”[have] come under so much attack”. Martin ﬁrst stated that with the focusing of programming style, ”the popularity of the no goto rule [was] in large part, due to the fact that it is a simple rule which does improve the code produced by most programmers”. This happened because the programmers were forced to solve new problems by using other constructs, which showed themselves to increase the programming style of the programmer. Martin E. Hopkins had the opinion that this reason alone ”sufﬁcient” enough to remove the GOTO statement completely from higher programming languages, but good enough to ”justify teaching alternative methods of programming to beginners or restricting its use on a project”.

In the further sections of his paper, Martin E. Hopkins stated several arguments against the removal of the GOTO statement from higher programming languages. His arguments not only included the increase in efﬁciency that a good use of GOTO could have, but also more abstract thoughts of the GOTO as a tool to invent new creative coding styles by more advanced programmers that may work better in terms of readability or efﬁciency than the existing styles so far.

Although most arguments that Hopkins states won’t apply to the general mass of programmers, the arguments still can be seen as valid points for keeping the GOTO statement. I’ll go further in depth to it in the later part of the paper.

2.4 B. M. Leavenworth [5] In the year 1972, another article was published by B. M. Leavenworth where he talked about the GOTO. The article was called ”Programming With(out) the GOTO” and talked about the history of the GOTO since the time the controversy began. He looked at some formal programming languages which tried to remove the GOTO from it and realized that in their pragmatic programming extensions the GOTO still has been included. In all the cases that he states, the developers of the language saw reason to include some form of GOTO either for matter of tradition or for ”convenience”, although not all called them ”GOTO”.

He talked about the fact that many programmers still after giving an equivalent way of replacing a GOTO statement in ALGOL and PL/I kept using the GOTO statement as a ”force of habit”

Leavenworth summarized a list of arguments for and against the replacement of the GOTO statement, as I will be doing in the further sections of this paper. I’ll see if those arguments for and against the GOTO are still valid today. 5

2.5 David R. Tribble [8]

David Tribble gives us one of the more recent approaches to the discussion, with a paper-like discussion he published in 2005 on his own website. He uses the programming constructs that are used today to show in which way they can lead to replace the GOTO constructs, but also keep given restrictions and problems in mind.

In his discussion, he ﬁrst makes an effort to analyze the famous paper of Dijkstra with historical knowl- edge about Dijkstra’s motivation behind his phrasing of words, and his mathematical background. After this, he lists different programming structures and ways that these can replace the GOTO statement. Here he focuses on constructs that are used by almost all current programming languages today with some exceptions regarding languages like LISP, Scheme or Prolog, which follow a different path. He does this by ﬁrst showing an example of the structure as code and then states which common usage of the GOTO statement was equivalent to this. Other than Knuth, at whose time some of the constructs used today was not existent, he goes from code without a GOTO to equivalent code using the GOTO.

After this, David R. Tribble gives programming constructs which can in some way be seen as GOTOs as the involved jumps, but in a way that ”Dijkstra’s maxim” is still fulﬁlled. Using these constructs instead of the original GOTO allows the elimination of the GOTO structure for certain problems, that before the existence of those structures showed to be a big problem.

David R. Tribble’s conclusion was that the use of those new constructs could allow the removal of the GOTO but there are still many programming languages out there which don’t allow the use of the named constructs. He affirmed Dijkstra’s believe about the danger of the unstructured use of GOTO and stated that ”programmers who must use languages that do not provide sufficiently flexible flow control statements should exercise restraint when using unstructured alternatives”. He named this the ”Tao of goto: knowing when to use it for good and when not to use it for evil”.

I see the discussion of David R. Tribble as a valuable source for examples of arguments for and against the GOTO, I’ll go into that in the further part of this paper.

2.6 An empirical study using Github [6]

The last big work that I plan on taking into account in this paper is no work from one single author, but rather from 7 authors. The name of the paper is called ”An empirical study of GOTO in C code from Github repositories” from the year 2015, making it the most recent work I’m using for this topic.

In the paper tries to ”empirically identify whether GOTO statements are used in a disciplined-and hence harmless-way or in the complex way that Dijkstra feared would be harmful”

By looking into 11627 repositories of Code ,written in the programming language C, from Github and doing ”a focused quantitative study on speciﬁc releases of six Open Source Software (OSS) projects” they tried to address the following two questions. 1. What are Goto statements used for? 2. Do developers remove/modify GOTO statements? 6

Before going into the conclusion of the authors I want to state some interesting numbers that I will refer to in a later time. The first thing to mention is that of all the projects that were examined 26,60% have at least 1 file that uses the GOTO statement. When looking into how the Goto was used the authors of the paper first looked at the files on a system level to distinguish what incentive for the code was. The result was that almost 85% of the files” were in the ”’Systems and Network’ domain”. The authors found two possible reasons for this: 1. C files in Github might be mostly system/networking purposes 2. GOTO is used mainly in system/networking files On the function level which was the second level, the authors looked at there were several reasons to use GOTO. I’ll go into some of them later in the paper again.

The conclusion of the authors was summarized by them in two statements. The ﬁrst one was that ”Most usages of the goto statements appear to be reasonable”. The usages of the GOTO followed patterns that would be ”handled by speciﬁc constructs in more modern languages”. An example of this would be error handling and the cleanup of variables that were not used anymore.

The second one was that ”Developers did not remove/modify goto statements in the post-release phase after four of the six projects”. In none of the projects the use of the GOTO statement resulted in any ”post-release bugs”.

To the ﬁndings of the authors despite the fact that GOTO statements were still used but ”mostly lim- ited to the cases where it actually offers an improvement over the alternatives.”

3 The Solution

In the section above I shortly summarized the work of different sources. I did this to give the reader an overview on what work has been done and what different direction the GOTO controversy has been looked at. This was by far not all work that there is, but it offers a brought range of perspectives to look at this topic.

In this section, I’ll try to link those views together and look at this topic from the standpoint of a prospec- tive owner of a bachelor degree in applied computer sciences. I’ll try to ﬁnd a structure to this by going over the arguments given in the different works and if possible apply the arguments of other works onto them. I also will try to keep in mind the currently used coding constructs and see if the arguments are still applicable today.

3.1 GOTO considered harmful The ﬁrst time the discussion about the GOTO statement arose with the article of Edsger W. Dijkstra. So I suppose it is ﬁtting to start with his arguments.

Dijkstra’s point was that the human ability to ”visualize processes [which are] evolving in time are poorly developed”. Under this angle, Dijkstra tried to show that the use of GOTO without restrictions 7 could be harmful to the ability to understand the code [2]. Dijkstra came from a mathematical standpoint. He augmented against the unrestricted GOTO by showing that with the currently given constructs of programming it was fairly easy to characterize them mathematically by using a dynamic textual index with an additional information on what procedure is currently running [2].

Reason for this characterization of the program code was to prove a shortened ”conceptual gap between the static program and the dynamic process” [2], which means the effort to understand the code by just reading it and seeing what is happening when the code is processed is minimized.

When adding what he called an ”unrestricted GOTO” the process of characterizing the code mathematically gets won’t be possible anymore in a meaningful manner [2]. This is due to the ability to jump forward and backward without any restrictions. You can reread about this in section 2.1.

The name that such a code that uses GOTO in such a way is often referred to as ”spaghetti code”.

Its called that because instead of just reading the code from top to bottom like we normally are doing, jumping in all directions prevents this. The ability of the GOTO to jump back up makes the necessity to keep a large number of commands in the mind, to understand completely what the program tries to do.

A code that is really hard to comprehend for a human reader of the code.

3.2 Restricted GOTO Dijkstra’s arguments have been generally accepted and even invoked movement to generally stay away from the use of GOTO. For many, this has been seen as a call to remove GOTO from higher programming languages completely, but he did not refer to the general use of GOTO but rather the ”unrestricted Use” of GOTO. Although the GOTO statement is still existent in many programming languages today and could still be used in an unrestricted way there are common uses of the GOTO statement even today that follow certain patterns to fulﬁll certain goals. I’ll go further into those in the later parts of this discussion. But for now, I want to try to explain, why I think the argument of Dijkstra does not apply to those uses of GOTO.

What all of those patterns that I am referring to have in common is that they are all jumping forward out of an existing loop or procedure. They effectively work as breaks that initialize new code sections out of a loop or another section. This makes them as understandable as all the other coding constructs that are used today. And by that, I wouldn’t necessarily call them bad. These patterns for the use of GOTO were put into its own constructs by some programming languages, but it seems that for some, as I suppose meaningful (I had trouble ﬁnding sources on that) reasons, not all programming languages decided to do so.

I’ll go a bit into detail to this at a later time again when we’re talking about current common uses of the GOTO statement.

At the end of his paper, Dijkstra talked about the possibility of new programming constructs being suggested. For those made the demand that new constructs of programming that are suggested in the future fulﬁll the requirement that they can be characterized in the ways that allow a programmer inde- 8 pendent coordinate system to describe the process in a helpful and meaningful way [2]. In the case of the examples above with jumps outward that is probably the case. At least if you see the GOTO as a call of another procedure out of the loop, but I have to confess that I didn’t ﬁnd any other paper to prove this and mathematically. Proving it myself would probably exceed the demands of this paper.

3.3 A fresh angle to old code Some years after the paper of Dijkstra Donald Knuth picked up the discussion about the GOTO. He tried to offer a balanced view on the use of the GOTO by on the one hand discussing ways to remove the GOTO for cases that were common for the use of the GOTO [4]. On the other hand Knuth showed cases where including the GOTO could offer ways to increase the efﬁciency of common code structures [4]. You can read more about this in section 2.2

One of the points that Knuth made in his paper was that with the common code structure of programming languages of his time the GOTO was hard to avoid in a productive and useful way. Often removing the GOTO had no effect on the readability of the code [4]. But he also stated that in the future those constructs will probably be developed [4].

Since the time Knuth wrote his paper 44 years passed and the syntax of the commonly used programming languages changed immensely compared to the languages that were used back then. I’m going pick up examples that Knuth used in his paper and try to convert them to the commonly used programming language C.

I choose C for this because when talking about efﬁciency most of the time C is stated to be the programming language of choice. In addition to this C which used on a daily basis by many programmers today lacks some constructs that allow getting rid of GOTO and by this, it offers some good examples for the uses of GOTO that are hard to avoid even today.

I’m not planning on converting all the code that Knuth stated, as this would be way much redundancy that won’t give much value. Constructs like the for-loop or the while-loop can replace the use of GOTO but those existed at the time Knuth wrote his paper, and he already gave enough examples of how to handle them. What I want to pick up are examples of Knuth, where I found, were either with the current constructs it would be easier to remove the GOTO, or I see the same problem still existing with the current programming languages.

Knuth’s arguments against the GOTO are deﬁnitely still valid today and many GOTOs can be easily removed by applying strategies in his code. My goal is to see if Knuth’s arguments especially the ones for the GOTO are still valid today.

3.3.1 The break-statement

The first example where Knuth was able to increase the speed and efficiency of a program but failed to remove the GOTO was in his hashing example [4]. The first big difference to the code that Knuth used is the existence of a break statement that allows you to jump out of a loop or switch construct but for this paper I decided to only address the loop case for simplicity. In some cases, like nesting a switch into a loop the same problems can occur, but the solution should be rather similar. The break statement for 9 loops was talked about by Knuth and it is used by almost all currently used programming languages that use loops.

As a quick explanation you have to know that h(x) works as a hash function and which takes values between 1 and m. The variable m is a bit larger than the number of items in the table. The empty po- sitions of the table are represented by 0. This has the goal to ﬁnd a certain value in an array and if not found add it. Further if found it should be documented in B ho often it as been looked for [4]. Example 3b: int i = h(x); while ( A[i] != x ){ i := h(x); if ( A[i] != 0 ){ while A[i] != x do i = i - 1; if A[i] != 0 } then i := i - 1 else if ( i = 0 ){ else if i = 0 i = m; then i := m; } else A[i] := x; B[i] := 0; else{ go to found; A[i] = x; fi; B[i] = 0; fi; break; found: B[i] := B[i]+1; } } B[i] := B[i]+1;

Figure 1: break example On the left in Figure 1 you see code from Knuth [4], whereas on the right you see the same code implemented by the more modern programming language C which allowed the use of the break statement. The use of the break statement, can be seen as a jump, and essentially there is no big difference to a GOTO statement, in this case. The exception is that the break statement has only one use and this is to break out of an existing loop. In this case, the break statement would be the better choice, as the programmer already knows exactly what the break statement is supposed to do. The GOTO statement could lead to more time needed to understand what it is for, especially if the code gets bigger. This gives an example in which way the GOTO statement can be removed with tools given today whereas it was not possible in the past if you would not want to pay the price of efﬁciency.

3.3.2 Event indicators Another construct that Knuth talked about which should help us to get rid of the loop problem, is the concept of event indicators [4].

Event indicators essentially allow writing loops with multiple exit events and react accordingly to the event that happened. Normally to do this one would either need a variable to see which event occurred or use the GOTO statement. But instead of preset variables, which would make it hard for the compiler to optimize the code event indicators could allow exactly this. For the GOTO statement, it seems a bit faster because the need to set a boolean variable and read it won’t be there, but the advantage of increasing the 10 efﬁciency via the compiler will fall aboard as well.

Knuth stated that his preferred way to implement event indicators would look like Figure 2 and Fig- ure 3 [4].

loop until or ... or repeat; then => ... => fi;

Figure 2: Knuths Event indicators: A

begin until or ... or end; then => ... => fi;

Figure 3: Knuths Event indicators: B

In the code in Figure 2 the ”begin” stands for a one-time iteration whereas the ”loop” construct in Fig- ure 3 is for a loop [4].

I did not ﬁnd an equivalent construct that was used in any modern programming language. Intuitively when encountering a problem like this I would use a switch case statement, with an enumeration. But when thinking of an equivalent to this I would probably use something like Figure 4.

The code in Figure 4 is not a total equivalent and I would in the most cases prefer the use of a switch case over the use of a statement like this. In the best case, the example in Figure 4 might be as good as the same construct realized with a GOTO statement. Given that the overhead of the function call compared a GOTO. Which might sometimes be the case, but often enough a function call itself can be expensive [7].

But besides from the cost itself that is probably higher than the GOTO, using functions which are not at the position of the actual code can deﬁnitely decrease the readability of the code, especially if the name of the function is badly chosen, or the functions don’t differentiate themselves very much from each other.

This construct can offer some advantages, but it won’t be able to create it at highest efﬁciency without the use of the GOTO statement. This is an example of an argument Hopkins was talking about. The existence of the GOTO allows advanced programmers to implement and come up with new constructs, 11

void main(){ ... if (condition for event 1){ event_1(); break; } if (condition for event 2){ event_2(); break; } }

void event_1(){ do some stuff } void event_2(){ do some stuff }

Figure 4: Event Indicator Implementation that might actually be helpful [3].

3.3.3 Break out of nested loops The above-stated construct is not necessary very often. Knuth himself stated that there were other ways to deal with problems that could allow the removal of the GOTO statement, that are as decent as the Event Indicator [4]. The alternative he has been referring to was a statement, that I talked about before in section 3.3.1, the ”break-statement”. The break statement allows jumping out of a loop immediately what would otherwise often be done with a GOTO statement. But Knuth talked about more than just the break statement alone, which only allows jumping out of one loop. Knuth talked about the necessity for a break statement, which allowed breaking out of nested loops [4].

Since today there are not that many ways to exit nested loops. When I tried to think about ways to do this I came up with 3 solutions.

The way that most of the time has been used was either to set a boolean variable which stands for a break condition. Something like Figure 5. A break like this is a possibility, but obviously not the best one. Especially when performance plays a big role the setting of a boolean could slow the program down

The second way uses a construct, that I used before in section 3.3.2, the construct of functions. For a programmer today the use of functions is something that is pretty clear. We use them all the time to break down our code in smaller more understandable junks. The main difference between a function today and a procedure which was used before the existence of functions is the fact that a function can, but not necessarily has to take input variables and return a result. The return of a result ends the function immediately which can be seen as a jump out of the function. 12

boolean breaking = false; while (codition_for_outer_loop){ ... while (codition_for_inner_loop ){ ... if (break condition){ breaking = true break; } } if (breaking){ break; } ... }

Figure 5: nested loops with break condition

A friend of mine came up with the idea for this when I talked about this topic with him, but I also read about this on a website called ”stackoverﬂow” [1].

In C code this would loop something like Figure 6.

void nestedFunction(){ while (codition_for_outer_loop){ ... while (codition_for_inner_loop ){ ... if (break condition){ return; } } ... } }

Figure 6: nested loop with function

The use of a void function allows to not return any value, but the return statement itself still functions as a break

One problem with this is that there are still cases where a function call like this might be more expensive then the last way. In C one could make the function an ”inline” function, which tells the compiler to try to write the code inside the function at the place of the function call instead of making a function call [7]. In the best case this would mean that the runtime would be equivalent to the last way in terms of 13 performance.

The other problem is that this might not always increase the readability of the code, the function would be needed to be deﬁned outside of another function, which leads to the code not being deﬁned in the same place as it is called. In some cases when a meaningful name for the function can be found easily or especially when the while loop itself is rather big this might actually be an advantage rather than a disadvantage, but that is highly depended on the scenario.

The last example is the use of the GOTO statement. It’s suggested by many programmers rather often when encountering this problem in C. You can see this example in Figure 7. In section 3.2 this use was one of the uses that I had in mind about this when referring to patterns that are still used and might actually not hurt to be used. It’s even a suggested way by David Tribble in his paper [8], which I talked about in 2.5. while (codition_for_outer_loop){ ... while (codition_for_inner_loop ){ ... if (break condition){ goto final; } } ... } final: ...

Figure 7: nested loop with GOTO The example in Figure 7 is in my opinion as readable as the other two and may in the most cases be the fastest. On the other hand speed like this is rarely needed today so whether to choose either of them depends highly on the scenario.

3.3.4 error-exits One of the problems that Knuth had when eliminating the GOTO statements from his code, was when facing the topic of error exits [4]. This is for example needed in the case of a memory overflow. In nor- mal cases, this can be avoided, if the code is written by only one person, and you would assume that this person makes sure that a memory overflow would not happen beforehand. This would further follow the thought that this one person doesn’t do mistakes, which is pretty unlikely. Assuming this in the regular work as a programmer is not a good idea. Even put aside that even the best programmer produces a bug or forgets to check for a memory overflow, when working with others this is even more important. Most of the programs written today are written by more than one person. And besides, there is always the possibility to use code written for another program in your project, to decrease the time to rewrite the same function over and over again. 14

This is an argument that is most of the time being named for the existence of the GOTO. This is ad- dressed as well by David Tribble in his given paper. David referred to this problem as ”Exception Handling” rather than error exits [8], which is what most of the modern programming languages are referring it by. David stated that ”[s]ome languages (notably the more recent object-oriented languages) provide exception handling mechanisms for dealing with synchronous error conditions, conditions while older languages do not” [8].

One of the programming language that is still used very often today, which do not provide exception handling mechanisms is C. I referred to that before in section 3.3 when explaining why I choose C for most of my code examples.

David Tribble showed how error handling would be done with a GOTO statement [8]. The code example will probably be way too big to bring it up in this paper, so I would advise you to look it up at his source. He also provided ways to do exception handling without the GOTO statement, but those came with some disadvantages [8].

The ﬁrst example, although it seems to be comparable in terms of efﬁciency uses duplicated code, which makes it harder to understand. The second example doesn’t use this, but on the other hand, it uses variables to indicate errors, which come with a cost of performance.

The above-given disadvantages are one reason, why the GOTO is chosen in this case very often. The other one is that the use of a GOTO in this way does not affect the readability of the code negatively [8]. Especially since it is only a forward and not a backward jump. I talked about this in section 3.2.

Another way to handle exceptions is the exception handling mechanisms that more modern programming languages use. Those mechanisms are using a ”try-catch statement” for example [8], This is cleaner in theory but has the ”disadvantage of requiring more overhead for managing the try and catch clauses, which can be fairly expensive” [8], as David Tribble did state it.

3.4 Main arguments against the GOTO In the sections above although I named some arguments against the GOTO the most of the arguments I brought up to this point seemed to speak for the GOTO statement to be kept. This topic won’t be totally treated until I talk about the stronger arguments that came up in the years of discussion. Leavenworth summarized some of them in his paper.

The ﬁrst one he mentioned which was discussed by others as well [2] and is mostly accepted for the majority of the cases is the following: • ”Goto-less programs are easier to understand, debug and modify” [5] I don’t think that I have to talk much about this topic. In most of the cases, this is true in my opinion. It is not that an easy to understand the program is not possible with the use of GOTO statements, but it is fairly easy to write so-called ”Spaghetti Code” with the use of GOTO.

The next argument that he talks about is the following. • ”If the goto statement is not replaced by more sophisticated control structures, the programmer is likely to misuse it...in order to synthesize those structures” [5] 15

In the previously stated cases, this showed itself true. For example, the break statement from nested loops is up until today still something that is implemented by used by GOTO. There are two questions that to be asked. The ﬁrst one is if this is actually really harmful. As argued by Hopkins for the GOTO stated, the use of the GOTO can help people to come up with new creative programming styles, which may even increase the overall style of code [3]. By this, the above argument could also be seen as something positive rather than something negative. On the other hand, those established styles when they follow a certain pattern could be easily made into ﬁx constructs, that can only be allowed in a certain context. By this, the code itself could become even easier to read as programmers will start to recognize those constructs. And know ahead of time what they were intended to achieve.

The third argument summarized by Leavenworth is the following: • ”It is easier to prove assertions about ’goto-less’ programs” [5] This is at least true for most of the cases where the GOTO statement is used. Dijkstra showed this in his paper pretty well.

3.5 Dangers of GOTO in praxis Up until now, I talked about arguments for and against the use of GOTO. To answer the question if GOTO could be removed from higher programming languages and if this would be something that would be helpful to increase the overall structure and style of programs. But now I want to look at the question if the existence of GOTO up to today really had that much of a negative effect on the quality of programs.

From the ﬁrst time, the discussion about the GOTO statement started up to today 50 years passed. The effects of this discussion can up to this day still be seen, as many people still advice against the use of GOTO. In the year 2015 a paper, with the name ”An empirical study of goto in C code from Github repositories” was released which talked about an empirical study about the use of GOTO [6].

The questions were not in theory if the use of the GOTO statement could potentially harm the quality of code, but instead if it did so in the last years.

The study only looked at C code, which as I stated above offers many reasons to still use the GOTO statement. But the use in this manner won’t be that hurtful.

As explained in section 2.6 the GOTO statement has been used in 26% of the projects. And of all the ﬁles that were looked 11.5% of the ﬁles that were looked at did contain GOTO statements [6]. This sounds like a rather high number, but you have to keep in mind that the Programming language was C which has as stated above a lack of certain constructs like error exits or breakouts of nested loops.

When looking at the exact ways the GOTOs were used in the functions the study found that the most of the GOTO statements for error handling and cleanup purposes [6]. The paper did state further that most of those uses were done systematically by locating the blocks at the end of the function. [6] On the other hand ”[o]nly a minority of functions use goto statements for other purposes, such as breaking out of nested loops, or creating loops in an ad-hoc manner.” [6] 16

This result indicates that the times when GOTO has been used were most of the time for a reasonable manner and not as feared by Dijkstra in an unrestricted way [2].

The study didn’t stop with this result they further for a number of Open Source Software projects if the use of GOTO would lead to bugs of any matter [6]. The study found that none of the projects had a noticeable number of bugs that could be traced back to the GOTO statement [6].

This study showed that although GOTO could lead to bad style in theory in praxis this is not the case in an amount that is worth mentioning.

4 Conclusions, Results, Discussion

In this paper, I looked over many arguments from different people and perspectives on the question if the GOTO should and if so could safely be removed from higher programming languages.

All arguments that I talked about were made under the acceptance of the paper of Dijkstra that talked about harm that the GOTO statement could bring to the overall style of Code when uses without restric- tion [2]. The overall view that the GOTO statement should be treated with caution and not be used unless there is no better alternative is pretty clear.

The question that I tried to answer as well was if there was even a reason to use GOTO at all. If perhaps the demand of Knuth came true, that in the future there will be enough control structures, that allows refraining from the use of the GOTO statement completely [4]. From what I showed that was not the case. There are still programming languages that don’t offer enough control structure to this day that would safely and without any cost allow the removal of the GOTO.

On the other hand, one could state that the control structures could probably be created to function for only one reason and disallow to be used for any other reason.

But even then the question comes up if not at one point, despite the existence of many useful and though trough constructs, the need for a new structure arises, which will ﬁrst by experienced programmers to get around the nonexistence.

Besides the big arguments for and against the GOTO one thing sticks out. The study I talked about in section 3.5. The fact that the use of the GOTO on today’s terms doesn’t seem to be used in dangerous terms noticeably often anymore [6] lets the question of the existence of the GOTO statement to still be harmful to the overall style of code, get pretty obsolete.

I think that the GOTO statement should stay existent in the landscape of programming languages, especially when performance is an issue. But as said if used, it should be taught to be used with caution.

Tribble referred to this as ”[t]he Tao of Goto” which was about ”knowing when to use it for good and when not to use it for evil” [8]. 17

5 Bibliography

References

[1] Srikar Appalaraju (2012 (accessed 13. August 2018): StackOverﬂow: how-to-break- out-of-nested-loops. Available at https://stackoverflow.com/questions/9695902/ how-to-break-out-of-nested-loops. [2] Edsger W. Dijkstra (1968): Letters to the editor: go to statement considered harmful. Communications of the ACM 11(3), pp. 147–148, doi:10.1145/362929.362947. Available at https://doi.org/10.1145/362929. 362947. [3] Martin E. Hopkins (1972): A case for the GOTO. ACM SIGPLAN Notices 7(11), p. 59, doi:10.1145/987361.987371. Available at https://doi.org/10.1145/987361.987371. [4] Donald E. Knuth (1974): Structured Programming with go to Statements. ACM Computing Surveys 6(4), pp. 261–301, doi:10.1145/356635.356640. Available at https://doi.org/10.1145/356635.356640. [5] B. M. Leavenworth (1972): Programming with(out) the GOTO. ACM SIGPLAN Notices 7(11), p. 54, doi:10.1145/987361.987370. Available at https://doi.org/10.1145/987361.987370. [6] Meiyappan Nagappan, Romain Robbes, Yasutaka Kamei, Eric´ Tanter, Shane McIntosh, Audris Mockus & Ahmed E. Hassan (2015): An empirical study of goto in C code from GitHub repositories. In: Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering - ESEC/FSE 2015, ACM Press, doi:10.1145/2786805.2786834. Available at https://doi.org/10.1145/2786805.2786834. [7] Steven Pigeon (2008 (accessed 13. August 2018): The tue const of calls. Available at https://hbfs. wordpress.com/2008/12/30/the-true-cost-of-calls/. [8] David R. Tribble (2005 (accessed 13. August 2018): Go To Statement Considered Harmful: A Retrospective. Available at http://david.tribble.com/text/goto.html.