# Goto statement, mostly regarding Fortran

by fluidistic
Tags: fortran, goto, statement
PF Gold
P: 3,166
Hey guys,
I've read that Borek (a member here) was told that the goto statement was "bad" during the 80's. I myself did some research on the Internet about that and it seems that:
1)Fortran used to have the goto statement up till Fortran 90.
2)It has been eradicated since Fortran 95.
 The 1960s and 1970s saw computer scientists move away from GOTO statements in favor of the "structured programming" paradigm.
I'd like to know why it is considered as "bad" to use the goto statement, particularly in Fortran but I wouldn't mind if someone reply for another language.

And also, how would you modify this part of one of my codes:
98 write(*,*)"In order to solve the linear system, do you want to use Jacobi(1)'s method or Gauss-Seidel(2)'s one?"
if (p==1) then
call jacobi(n_max,n,tol)
else if (p==2) then
call gauss(n_max,n,tol)
else
goto 98
end if
It seems so intuitive and efficient that I'm really curious what's "bad" about it and what would be the "correct" version according to nowadays programmers.
Thanks a bunch in advance! (I'm really eager to know!)
 Mentor P: 11,044 My experience with Fortran ended with the extended version of Fortran 77 that was available on VAX and Prime computers, so I'll use C++ for my two goto-less versions. This one most resembles your version: cout << "In order to solve […]? "; do { cin >> p; if (p == 1) jacobi (n_max, n, tol); else if (p == 2) gauss (n_max, n, tol); else cout << "Please choose a valid option (1 or 2): "; } while ( ! ((p == 1) || (p == 2)) ) I personally would use the following version, which separates asking for the choice from actually performing the choices: // Find out which algorithm to use. cout << "In order to solve […]? "; cin >> p; while ( ! ((p == 1) || (p == 2)) ) { cout << "Please choose a valid option (1 or 2): "; cin >> p; } // Perform the chosen algorithm. At this point we are guaranteed // that p is either 1 or 2. if (p == 1) jacobi (n_max, n, tol); else gauss (n_max, n, tol);
 P: 73 Goto statements in any language make for hard to read code and are an inefficient way to do things. Your example of code is very simple and easy to follow, so it does not fall into the above category, but for example,  do 110 i=1,2000 if(a .ge. b(i)) then go to 110 endif indx = i go to 112 110 continue indx = 2000 112 z = float(indx-2)*c + c*(a - b(indx-1))/(b(indx) - b(indx-1)) This is a very confusing snippet of code utilizing goto statements. Which is extremely hard to follow and see what is going on.
HW Helper
P: 6,180

## Goto statement, mostly regarding Fortran

We like to call it "spaghetti".
You can compare it to a rope that has become entangled.
As you may know it takes a lot of skill and effort to discern how it is entangled.
And it is a lot of work to untangle it.
Mentor
P: 20,433
 Quote by fluidistic Hey guys, I've read that Borek (a member here) was told that the goto statement was "bad" during the 80's. I myself did some research on the Internet about that and it seems that: 1)Fortran used to have the goto statement up till Fortran 90. 2)It has been eradicated since Fortran 95.
I don't believe goto has been "eradicated" since Fortran 95. The wiki article on Fortran 95 (http://en.wikipedia.org/wiki/Fortran_language_features) says this:
"The simple GO TO label exists, but is usually avoided — in most cases, a more specific branching construct will accomplish the same logic with more clarity."
 HW Helper P: 6,903 A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative: http://www.physicsforums.com/showthread.php?t=308782
 HW Helper P: 805 It's hard to follow and can get pretty insane if you have multiple goto's all over the place. Anyone trying to debug tons of goto's will probably throw their computer out the window.
HW Helper
P: 6,180
 Quote by rcgldr A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative: http://www.physicsforums.com/showthread.php?t=308782
Let's not make such a long spaghetti thread here!

(I think there are goto's in it! )
 Emeritus Sci Advisor PF Gold P: 16,101 One of the ideals of writing a program is that it should be self-documenting. A WHILE loop or a FOR loop are somewhat more descriptive than the equivalent construct built out of GOTO and IF-THEN statements. Most commonly needed ways to control the flow of your program can be more concisely and clearly described via methods without invoking a GOTO statement. Many of the exceptions can be rearranged into a simpler program that doesn't use GOTO. A lot of the GOTO hate is unwarranted, however. It's like the pirates vs global warming thing -- once upon a time GOTO was more or less all that was available, and people frequently wrote spaghetti* code. So people blamed GOTO as actually being the cause, rather than the lack of options simply being correlated with programming attitudes of the time. And, of course, there is also some naivety of the form "if we forbid GOTO, then people can't write spaghetti code!" which motivates some more of the GOTO hate. Sometimes, GOTO hate is taken to an extreme, turning into hate for BREAK, CONTINUE, some uses of exception handling, or even a RETURN that appears someplace other than the very last line of a function. *: Spaghetti code is so named because it's not clear (or even impossible!) to tell what is happening in the program without paying very careful attention to the thread of execution as it winds through the program. Also, there is the subsequent problem that it is very difficult to modify the program.
 HW Helper P: 6,180 For myself, I agree with your point of view on goto and other forms. However, having worked in projects where lots of different junior programmers come along, I found it is best to keep the programming style rules simple and predictable.
PF Gold
P: 3,166
Thanks a lot to you all guys for the insights. Too much to answer for me!
First, sorry I hadn't searched in PF about goto. The mentioned thread that rcgldr posted seems very interesting.
About jtbell: Too bad I don't know C++ at all. But looking carefully at your code I can understand some stuff. However I do not see where is the "goto" statement in your first code.
To Mark44, thanks for the link. Actually what I read on Fortran page seems different? Or my English is too bad so that I misunderstand. What do you say:
 Quote by Wikipedia Several features noted in Fortran 90 to be deprecated were removed from Fortran 95: DO statements using REAL and DOUBLE PRECISION variables Branching to an END IF statement from outside its block PAUSE statement ASSIGN and assigned GOTO statement, and assigned format specifiers H edit descriptor.
What do you understand from this? What I understand is that Fortran 95 doesn't have the "goto" statement anymore.

And swartizm, here is your code:
 do 110 i=1,2000
if(a .ge. b(i)) then
go to 110
endif
indx = i
go to 112
110  continue

indx = 2000
112  z = float(indx-2)*c + c*(a - b(indx-1))/(b(indx) - b(indx-1))
Would that even compile?! I mean, I never seen
do 110 i=1,2000
.
Did you mean
do i=110,2000
?
 Mentor P: 20,433 What they removed from Fortran 95 was the assigned GOTO statement, which is described here - http://www.nsc.liu.se/~boein/f77to90/a2.html. That's not the same as the plain old GOTO statement. The code that swarzism provided is an older style (Fortran 77?). The line number in the do statement refers to the line number of a continue statement. do 110 i = 1, 2000 ! some stuff 110 continue The code in the preceding sample is equivalent to this code: do i = 1, 2000 ! some stuff end do
PF Gold
P: 3,166
 Quote by Mark44 What they removed from Fortran 95 was the assigned GOTO statement, which is described here - http://www.nsc.liu.se/~boein/f77to90/a2.html. That's not the same as the plain old GOTO statement. The code that swarzism provided is an older style (Fortran 77?). The line number in the do statement refers to the line number of a continue statement. do 110 i = 1, 2000 ! some stuff 110 continue The code in the preceding sample is equivalent to this code: do i = 1, 2000 ! some stuff end do
Ah thanks, now I understand swartizm's code.
About assigned goto statement, I'm not understanding the difference with the goto statement.
For instance,
 ? GOTO (snr1, snr2, snr3), integer_expression - conditional GOTO statement. If the integer expression is 1, 2 or 3, execution jumps to statement number snr1, snr2 or snr3 (an arbitrary number of statement numbers snr are permitted). ??GOTO statement_number_variable, (snr1, snr2, snr3) - an assigned GOTO statement, jumps to the statement number that equals the statement number variable (an arbitrary number of statement numbers snr are permitted).
For the first goto, I could write
goto (100, 156, 200), 2
. It would be the same as if I write
goto 156
.
For the second, if I understand well, I could write
goto 354 (15, 98, 354)
and it's the same as if I write
goto 354
.
The first looks like allowed in Fortran 95 while the second not.
Hmm I'm sure I don't get it.
P: 4,568
 Quote by fluidistic Hey guys, It seems so intuitive and efficient that I'm really curious what's "bad" about it and what would be the "correct" version according to nowadays programmers. Thanks a bunch in advance! (I'm really eager to know!)
That's the thing. A goto statement is non intuitive for most programmers.

A goto is just a form of flow-control that does not have context information. Let me explain what I mean.

When you write branching code like an if statement: you can easily read the branching conditions in the if statement and see exactly what it is doing in terms of the criteria of the branch and change in flow control. You see what variables affect the change and you can follow what the program is doing.

Its the same sort of argument with loops both conditional and unconditional. Same with recursive functions: in all these examples you are able to relate easily the flow control of the program with the state space that is being read or written.

With the goto statement, it's hard to readily identify the type of context mentioned above, not only with respect to flow control in its own right (ifs, loops, select, case, function calls etc), but also its relation to the state space of the program.
HW Helper
P: 6,903
 Quote by chiro A goto statement is non intuitive for most programmers.
I think the average person understands the concept of "goto", go to the store, go to Lombard Street, ... . The average programmer isn't going to have problems realizing that "goto xyz" transfers code to the line labeled "xyz:".

 A goto is just a form of flow-control that does not have context information.
Rarely is goto used in a non-context mode. It's normally used as part of a conditional sequence such as if(...){ ...; ...; goto xyz;} That previous thread pretty much explained the situations where using goto would be good or bad:

P: 4,568
 Quote by rcgldr I think the average person understands the concept of "goto", go to the store, go to Lombard Street, ... . The average programmer isn't going to have problems realizing that "goto xyz" transfers code to the line labeled "xyz:". Rarely is goto used in a non-context mode. It's normally used as part of a conditional sequence such as if(...){ ...; ...; goto xyz;} That previous thread pretty much explained the situations where using goto would be good or bad: http://www.physicsforums.com/showthread.php?t=308782
Of course goto is easy to understand, but if you're a programmer with some experience, you are expecting clean structured code, and this kind of thing is disrupted with a goto statement. It's more of a forest from the trees approach: experienced programmers can look at well written code and decipher what the code is all about when the code is written well, but it can be very difficult to get this kind of grasp when the code is poorly written, and that includes unnecessary use of things like goto. Again I emphasize not just understanding what a single line of code does, but more along the lines of interpreting the whole subroutine at a higher level.
 P: 73 The DO/CONTINUE format that I gave an example of is still used in 90,95,2003 and is even faster than DO/ENDDO. I wrote a small explanation why in the thread http://www.physicsforums.com/showthread.php?t=504768
Emeritus