During a conversation recently with one esteemed programmer, I discussed the usage of goto statements. I started programming academically in Fortran where the goto statement was ultimately one of the most important piece. This was carried forward when programming in Basic and early variants of VB.
Somehow when we moved to C and especially C++ this practice was deemed as a fatal error. I think the later variants of C++ don’t even allow the goto statement anymore, but back then C gave you the option to jump your logic using a goto statement when using gcc.
So while researching I came acrosss two exceptionally well written points of view. One of them is by Dijkstra who I introduced to you all here. The other one comes from Frank Rubin.
Here are the opposing points of View:
Dijkstra States:
Click on the link below for the complete paper presented by him in 1968.
The unbridled use of the go to statement has an immediate consequence
that it becomes terribly hard to find a meaningful set of coordinates in
which to describe the process progress. Usually, people take into account
as well the values of some well chosen variables, but this is out of the
question becuase it is relative to the progress that the meaning of these
values is to be understood! With the go to statement one can, of course,
still describe the progress uniquely by a counter counting the number of
actions performed since program start (viz. a kind of normalized clock).
The difficulty is that such a coordinate, although unique, is utterly
unhelpful: in such 8 coordinate system it becomes an extremely complicated
affair to define all those points of progress where, say, "n" equals the
number of persons in the room minus one!
Frank Rubin’s take on the Statement:
“Let X be an N x N matrix of integers. Write a program that will print the number of the first all-zero row of X, if any.”
Three of the test group regularly used GOTOs in-their work. They produced seven-line programs nearly identical to this:
The other ten programmers normally avoided GOTOs. Eight of them produced 13 or 14-line programs using a flag to indicate when an all-zero row was found. (The other two programs were either incorrect or far more complex.) The following is typical of the programs produced:
After reviewing the various GOTO-less versions, I was able to eliminate the flag, and reduce the program to nine lines:
By any measure not intentionally biased against GOTOs, the two GOTO-less programs are more complex than the program using GOTOs. Aside from fewer lines of code, the program with GOTOs has only 13 operators, compared to 21 and 19 for the GOTO-less programs, and only 41 total tokens, compared to 74 and 66 for the other programs. More importantly, the programmers who used GOTOs took less time to arrive at their solutions.
In recent years I have taken over a number of programs that were written without GOTOs. As I introduce GOTOs to untangle each deeply nested mess of code, I have found that the number of lines of code often drops by 20-25 percent, with a small decrease in the total number of variables. I conclude that the matrix example here is not an odd case, but typical of the improvements that using GOTOs can accomplish. I am aware that some awful programs have been written using GOTOs. This is often the fault of the language (because it lacks other constructs), or the text editor (because it lacks a block move). With a proper language and editor, and adequate instruction in the use of GOTO, this should not be a consideration. All of my experiences compel me to conclude that it is time to part from the dogma of GOTO-less programming. It has failed to prove its merit.
So I have given you both the sides and I’ll let you decide. Even though I respect Dijkstra a lot and regard him as an authority in Computer Science, I would have to disagree with him on the use of the GOTO statement. C language has break and continue statements which are sorts of a goto – and everyone uses these somehow, somewhere to get something done.