Register to reply

Goto statement, mostly regarding Fortran

by fluidistic
Tags: fortran, goto, statement
Share this thread:
fluidistic
#1
Jun28-11, 12:40 PM
PF Gold
fluidistic's Avatar
P: 3,188
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.
3)In wikipedia one reads
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?"
read(*,*)p
if (p==1) then
call jacobi(n_max,n,tol)
else if (p==2) then
call gauss(n_max,n,tol)
else 
write(*,*)"Please choose a valid option"
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!)
Phys.Org News Partner Science news on Phys.org
Sapphire talk enlivens guesswork over iPhone 6
Geneticists offer clues to better rice, tomato crops
UConn makes 3-D copies of antique instrument parts
jtbell
#2
Jun28-11, 02:00 PM
Mentor
jtbell's Avatar
P: 11,614
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);
swartzism
#3
Jun28-11, 02:58 PM
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.

I like Serena
#4
Jun28-11, 03:12 PM
HW Helper
I like Serena's Avatar
P: 6,187
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.
Mark44
#5
Jun28-11, 03:20 PM
Mentor
P: 21,216
Quote Quote by fluidistic View Post
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."
rcgldr
#6
Jun28-11, 04:15 PM
HW Helper
P: 7,033
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
gb7nash
#7
Jun28-11, 04:19 PM
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.
I like Serena
#8
Jun28-11, 04:22 PM
HW Helper
I like Serena's Avatar
P: 6,187
Quote Quote by rcgldr View Post
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! )
Hurkyl
#9
Jun28-11, 04:48 PM
Emeritus
Sci Advisor
PF Gold
Hurkyl's Avatar
P: 16,099
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.
I like Serena
#10
Jun28-11, 05:01 PM
HW Helper
I like Serena's Avatar
P: 6,187
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.
fluidistic
#11
Jun28-11, 05:37 PM
PF Gold
fluidistic's Avatar
P: 3,188
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 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
?
Mark44
#12
Jun28-11, 06:05 PM
Mentor
P: 21,216
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
fluidistic
#13
Jun28-11, 07:13 PM
PF Gold
fluidistic's Avatar
P: 3,188
Quote Quote by Mark44 View Post
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.
chiro
#14
Jun28-11, 11:21 PM
P: 4,572
Quote Quote by fluidistic View Post
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.
rcgldr
#15
Jun28-11, 11:59 PM
HW Helper
P: 7,033
Quote Quote by chiro View Post
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:

http://www.physicsforums.com/showthread.php?t=308782
chiro
#16
Jun29-11, 12:27 AM
P: 4,572
Quote Quote by rcgldr View Post
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.
swartzism
#17
Jun29-11, 09:36 AM
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
Hurkyl
#18
Jun29-11, 05:58 PM
Emeritus
Sci Advisor
PF Gold
Hurkyl's Avatar
P: 16,099
Quote Quote by chiro View Post
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")


Register to reply

Related Discussions
Fortran 90, goto Programming & Computer Science 13
FORTRAN 77 read statement Engineering, Comp Sci, & Technology Homework 4
FORTRAN Write Statement Issue Programming & Computer Science 2
Meaning for fortran statement Programming & Computer Science 1
Fortran 90 very basic question : else if statement Programming & Computer Science 6