Vous êtes sur la page 1sur 24

The publishing of the paper entitled

Go To Statement Considered
Harmful, written by Edsger W.
Dijkstra in 1968, marked the
beginning of the debate on whether it
is appropriate to use the goto
statement in a well-structured
program.

Topic debated till the late 1970s,
when the debate died down
What is goto?
GOTO is a command found in many
programming languages which instructs
the computer to jump to another point in
the computer program.

It is the fundamental operation which can
be used for transfer of control from one
part of a program to another.
GOTO is found in FORTRAN, COBOL,
BASIC, C, C++, Pascal, Perl and
many other languages, particularly
assembly languages

In the assembly languages, the
GOTO command is usually called JMP
or JUMP, and is often the only way of
organizing program flow.
Simple Example of GOTO
If ( a == 5)
goto aLabel

Else{
a = a -5
b++
}

aLabel: a = b+1




One of E.W. Dijkstras arguments in his
paper was that the use of goto statements
produces incomprehensible spaghetti code


Spaghetti code is a term for code with a
complex and tangled control structure,
especially one using many GOTOs,
exceptions, or other "unstructured"
branching constructs. It is named such
because program flow tends to look like a
bowl of spaghetti.
Example of spaghetti code
$test = 1;
loop:
if($test == 0)
goto loopend;
if($var == 1)
{
$var = 3;
goto preloop;
}
If($var == 2)
goto var_7;
if($var == 7)
{
var_7:
$var = 9;
goto preloop;
}
$var = $var + 5;
$test = 0;
preloop:
$var = $var - 1;
goto loop;
loopend:
Same code without goto
$test = true;
while($test)
{
switch($var)
{
case 1:
$var = 3;
break;
case 2:
case 7:
$var = 9;
break;
default:
$var += 5;
$test = false;
break;
}
$var -= 1;
}

Main arguments against GOTO
Makes your code unreadable to the
others
Will lead to spaghetti code really fast
GOTOs are in strong opposition to
code reusability and object
orientation
Its a pain to debug GOTOs
Unreadable code:
If you write code as in previous
spaghetti code example then it will be
unreadable. You must stick to using it
infrequently or only when it makes the
program easier to write.

Will lead to spaghetti code really fast

You must be a responsible
programmer and not use gotos
everwhere in your program so that it
leads to spaghetti code.

Metaphor of driving a porche vs.
driving a honda
no reusability and object orientation
Object orientation is a way to organize your
program as a whole, at a completely other
level than the implementation itself
You musnt confuse object oriented
programs with high-level programs and
goto statements with low-level
programming.

Reusability
Same argument as previous slide.
Object orientation does not create
reusable code, programmers do

cannot debug
Justified use of GOTO statements
does not hinder debugging
Proper use of goto
The problem with using goto isnt the
construct itself

Its the use of goto in the
appropriate places. The goto
statement can be a useful tool in
structuring program flow
Example use of goto statment
while (true)
{
read in a value
if (value == xl)
then
goto value_found
else
process the value
}
Value_found:
//...
Same code without goto
read in a value
while (value != sentinel)
{
process the value
read in a value
}
//...

the second approach has two major
drawbacks:

First, it duplicates the statement to
read in a value. Duplication of code
leads to maintenance problems:
Modification of the code at one place
must be repeated at every other
place where it has been duplicated
The key to writing solid code is to write
code that reads naturally.

What youre trying to do is: You read in a
value. If the value is a sentinel you stop.
Otherwise, you process the value and
continue to read the next value.

second piece of code reverses your natural
way of thinking about the problem
When GOTO is necessary
Sometimes certain code is very hard
to write without the use of a GOTO


int first_zero_row = -1; /* none */
int i, j;
for (i = 0; i < n; i++) {
for (j = 0; j < n; j++)
{
if (A[i][j]) goto next;
}
first_zero_row = i;
break;
next: ;
}
Gotos and better Memory management
int method1(){
char *ptr = malloc(1024);
char *ptr1 = malloc(1024);
char *ptr2 = malloc(1024);
if ( method2(ptr) != 0 ){
free(ptr);
free(ptr1);
free(ptr2);
return 0; }
if ( method3(ptr1) != 0)
{
free(ptr);
free(ptr1);
free(ptr2);
return 0;
}
if ( method4(ptr2) != 1)
{
free(ptr);
free(ptr1);
free(ptr2);
return 1;
}
free(ptr);
free(ptr1);
free(ptr2);
}
This is a lot of extra
code and its all messy
and when this method
grows, in each return
we have to free any
allocated memory. If
programmer forgets,
then method1 is run
many times, it may
result in a core dump
or segmentation fault
Better memory management with goto
int method1(){
char *ptr = malloc(1024)
char *ptr1 = alloc(1024);
char *ptr2 = alloc(1024);
int ret = 0;
if ( method2(ptr) != 0 )
{
ret=0;
goto done;
}
if ( method3(ptr1) != 0)
{
ret=0;
goto done;
}
if ( method4(ptr2) != 1)
{
ret=1;
goto done;
}

done:
free(ptr);
free(ptr1);
free(ptr2);
return ret; }

This is
cleaner, lot
less prone to
memory
leaks, as
there is only
one exit point
and code is
much cleaner
to understand
Conclusion

Goto statements are harmful when
they are used carelessly

If responsible programming is used
then goto statement can be of a
great benefit.




THE END

Vous aimerez peut-être aussi