# Goto statement, mostly regarding Fortran

• Fortran
• fluidistic
In summary: This is tedious and error prone. If your "spaghetti" is very bad, it's actually less work to throw it away and re-write it!That's where the hate comes from. There are better ways to do things. But, as I've said, there are exceptions. It's worth knowing about them, and even using them, when you need them.In summary, the conversation discusses the use of goto statements in programming, particularly in Fortran. It is mentioned that Fortran used to have goto statements
fluidistic
Gold Member
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:
Code:
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!)

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:

Code:
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:

Code:
// 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);

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,

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))

This is a very confusing snippet of code utilizing goto statements. Which is extremely hard to follow and see what is going on.

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.

fluidistic said:
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."

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.

rcgldr said:
A previous and long thread about goto's. In some situations, for some programmers, they're better than the alternative:

Let's not make such a long spaghetti thread here!

(I think there are goto's in it! )

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.

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.

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:
Wikipedia said:
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:
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
Code:
do 110 i=1,2000
.
Did you mean
Code:
do i=110,2000
?

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.
Code:
do 110 i = 1, 2000
! some stuff
110 continue

The code in the preceding sample is equivalent to this code:
Code:
do i = 1, 2000
! some stuff
end do

Mark44 said:
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.
Code:
do 110 i = 1, 2000
! some stuff
110 continue

The code in the preceding sample is equivalent to this code:
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
Code:
goto (100, 156, 200), 2
. It would be the same as if I write
Code:
goto 156
.
For the second, if I understand well, I could write
Code:
goto 354 (15, 98, 354)
and it's the same as if I write
Code:
goto 354
.
The first looks like allowed in Fortran 95 while the second not.
Hmm I'm sure I don't get it.

fluidistic said:
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.

chiro said:
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:

rcgldr said:
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:

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.

chiro said:
Of course goto is easy to understand, but if you're a programmer with some experience, you are expecting clean structured code,
I don't care about "structured code".

I care about usable, readable, maintainable, and when appropriate, efficient code. When "structured programming" interferes with those goals, I don't use it, and neither should you.

(aside: I'm using scare quotes to emphasize the fact that "structured code" doesn't mean "code that is well-structured")

If you want to refactor, or get rid of, goto's in fortran code, there is a good free program for linux or windows, spag from polyhedron:
http://www.polyhedron.com/pflinux0html
This will refactor 60-80% of the goto's from your code.

I wrote a program I call remgoto that I use to remove all the remaining
goto's from fortran code, but I am still testing before releasing it. Search for "remgoto fortran".

## What is a Goto statement in Fortran?

A Goto statement in Fortran is a type of control flow statement that allows the program to jump to a different section of code based on a specified label. It is often used for implementing loops or conditional statements.

## Why is the use of Goto statements discouraged in modern programming?

The use of Goto statements is discouraged in modern programming because it can lead to spaghetti code, making the program difficult to read and debug. It also makes it harder to follow the logical flow of the program, making it more prone to errors and difficult to maintain.

## Can Goto statements be nested in Fortran?

Yes, Goto statements can be nested in Fortran. However, it is generally not recommended as it can make the code even more complicated and difficult to understand.

## Are there any alternatives to using Goto statements in Fortran?

Yes, there are alternatives to using Goto statements in Fortran. These include using structured control flow statements such as if-else and do-while loops, as well as using subroutines and functions to break up the code into smaller, more manageable chunks.

## Can Goto statements be used in modern programming languages?

Yes, some modern programming languages do support Goto statements. However, their use is still discouraged for the same reasons as in Fortran. Most modern languages provide alternative, more structured control flow statements that are easier to read and maintain.

Replies
12
Views
1K
Replies
11
Views
2K
Replies
6
Views
2K
Replies
8
Views
4K
Replies
2
Views
1K
Replies
6
Views
2K
Replies
5
Views
1K
Replies
3
Views
2K
Replies
13
Views
7K
Replies
4
Views
1K