GOTO controversy 
Author Message
 GOTO controversy


        : Although some people feel that the GOTO statement/structure in programming is
        : terrible (hard-to-follow spaghetti code), I think it is a necessary component
        : of any language.  It is the most versatile looping structure (can be adapted
        : to pre-test, post-test conditions with an IF, can take you anywhere) and is
        : closest to machine language.  
        : I am trying to get a feel for how people feel about the GOTO statement...
        : please post..

---The GOTO statement isn't needed for the basic looping
structures of pre-test, post-test etc.

   These are more than adequately handled with the
(structured) DO loop typified by:

DO K = 1 TO N;
 ...
END;

DO WHILE (A>B);
 ...
END;

DO UNTIL (A>B);
 ...
END;

   The indiscriminate use of GOTO for such types
of loop control results in "spaghetti programming",
which renders a program more-or-less unintelligible.



Fri, 14 Aug 1998 03:00:00 GMT  
 GOTO controversy


        >: I am trying to get a feel for how people feel about the GOTO statement...
        >: please post..

        >Somebody at school saw a goto in my code and freaked. Then again, this
        >person (who shall remain nameless) is used to machines with 100MB of
        >memory and dual SPARC CPU's. I on the other hand am not.

        >The code in question was a routine that allocated various resources.
        >Below is an example of such a thing (this time using OS/2 & C). I use Goto's
        >to clean up the mess in the event of an error.

        >Example for a good use of goto:
---                    ????
        >------------------------------------------------------------------------------

        >   HEV    hev1, hev2, hev3;     /* Event semaphores */
        >   HMTX   hmtx;                 /* Mutex semaphore  */
        >   void  *ptr;              

        >   if (!DosCreateEventSem(0, &hev1, 0, FALSE))
        >       goto hev1_failed;

        >   if (!DosCreateEventSem(0, &hev2, 0, FALSE))
        >       goto hev2_failed;

        >   if (!DosCreateEventSem(0, &hev3, 0, FALSE))
        >       goto hev3_failed;

        >   if (!DosCreateMutexSem(0, &hmtx, 0, FALSE))
        >       goto hmtx_failed;

        >   if ((ptr = malloc(SOME_SIZE)) == NULL)
        >       goto malloc_failed;

        >   /* Do some stuff here */
        >   return TRUE; /* We did okay */

        >malloc_failed:
        >   DosCloseMutexSem(hmtx);
        >hmtx_failed:
        >   DosCloseEventSem(hev3);
        >hev3_failed:
        >   DosCloseEventSem(hev2);
        >hev2_failed:
        >   DosCloseEventSem(hev1);
        >hev1_failed:
        >   return FALSE;

Is there any reason why the GOTOs can't be replaced by
the particular action routine?

You have the action routines separated from their
respective IFs, by a bunch of code (which may be large).
It makes it clumsy to read such code.



Fri, 14 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

>Is there any reason why the GOTOs can't be replaced by
>the particular action routine?

Yup. Clearly, if malloc fails we have 5 calls to clean up; each
successive error needs fewer cleanup calls.

I have encountered the same thing with simple files, and with
allocation of complex linked structures. It is almost always
true that GOTOs are misused, but not exclusively, and there are
places where it cleans things up a bit.

Quote:
>It makes it clumsy to read such code.

Not if it is all on the same page.

--

Laboratory for Computer Vision
Department of Computer Science                  403-220-6784
University of Calgary                           403-284-4707 (FAX)



Sat, 15 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:


>[original code example deleted for brevity, see

>>Is there any reason why the GOTOs can't be replaced by
>>the particular action routine?

>As he said, backtracking. The alternative would be to include yet another
>function call in each successive if-sentence, making the code ugly.
>Using gotos, the code _can_ be made to express the intended flow much
>better, as in his example.

>Are there any other languages than Prolog that implement a "machine" for
>backtracking?

Yup: C++, through destructors.


Sat, 22 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

> I am trying to get a feel for how people feel about the GOTO statement...
>: please post..

>Somebody at school saw a goto in my code and freaked. Then again, this
>person (who shall remain nameless) is used to machines with 100MB of
>memory and dual SPARC CPU's. I on the other hand am not.
>The code in question was a routine that allocated various resources.
>Below is an example of such a thing (this time using OS/2 & C). I use Goto's
>to clean up the mess in the event of an error.

>Example for a good use of goto:
>---                    ????
>------------------------------------------------------------------------------
>   HEV    hev1, hev2, hev3;     /* Event semaphores */
>   HMTX   hmtx;                 /* Mutex semaphore  */
>   void  *ptr;              
>   if (!DosCreateEventSem(0, &hev1, 0, FALSE))
>       goto hev1_failed;

>   if (!DosCreateEventSem(0, &hev2, 0, FALSE))
>       goto hev2_failed;
>   if (!DosCreateEventSem(0, &hev3, 0, FALSE))
>       goto hev3_failed;

>   if (!DosCreateMutexSem(0, &hmtx, 0, FALSE))
>       goto hmtx_failed;

>   if ((ptr = malloc(SOME_SIZE)) == NULL)
>       goto malloc_failed;

>   /* Do some stuff here */
>   return TRUE; /* We did okay */

>malloc_failed:
>   DosCloseMutexSem(hmtx);
>hmtx_failed:
>   DosCloseEventSem(hev3);
>hev3_failed:
>   DosCloseEventSem(hev2);
>hev2_failed:
>   DosCloseEventSem(hev1);
>hev1_failed:
>   return FALSE;

The above is NOT an example of a good use for the goto statement. A lot
of programmers hate goto with fanatical fervor. I personally feel they
can make for better code in certain situations. The first situation would
be to eliminate multiple return statements. A goto branch to a SINGLE label
is greatly preferable to multiple return statements with several exit points.
A subroutine with a single exit point is a lot easier to maintain than one
with several exit points. The second situation would be to break out of a
nested loop. The alternative to a goto in this situation is to use of flag
of some kind (while(more_data)), but this tends to make the code larger and
harder to read. Some more guidelines to follow for goto's are:

 DON'T use a goto unless it's the only solution to the problem.
 You have many alternatives to a goto in your above code.

 A subroutine should have at most one label.

 All goto's should be above that label in the code.

 The label should be in the same code block or at a more outer nesting level
 than the goto itself.

Your code could be easily reorganized to not use a goto.

-John



Sun, 23 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:
>Are there any other languages than Prolog that implement a "machine" for
>backtracking?

To my certain knowledege: SNOBOL and Icon.
I've heard it but can't verify it:  SETL.
One person at Arizona in the Icon project even wrote a preprocessor
to provide backtracking in C.

--
The election is over, and Australia lost; the idjits elected _politicians_!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.



Mon, 24 Aug 1998 03:00:00 GMT  
 GOTO controversy

[snip]
:  DON'T use a goto unless it's the only solution to the problem.
:  You have many alternatives to a goto in your above code.

Wrong.  'goto' will never be the only solution.  When the 'goto'
solution is more elegant than the other choices (which is entirely
possible), use 'goto'.

:  A subroutine should have at most one label.

Arbitrary number.  Does a subroutine with exactly *two* labels
automatically and magically become unreadable?

:  All goto's should be above that label in the code.

Above?  You mean all 'goto's should be forward jumps?  Why?

:  The label should be in the same code block or at a more outer
:  nesting level than the goto itself.

: Your code could be easily reorganized to not use a goto.

That's the point against using 'goto's.  Realize however that a
good engineer is usually smarter than blind guidelines.  The
rules you raised have obvious drawbacks.  Personally, the rule
I impose upon myself is: "If you use a 'goto', you better have
a damn good reason for it and be prepared to explain why all
other constructs make the program uglier."



Mon, 24 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

>A lot of programmers hate goto with fanatical fervor. I personally feel they
>can make for better code in certain situations. The first situation would
>be to eliminate multiple return statements. A goto branch to a SINGLE label
>is greatly preferable to multiple return statements with several exit points.
>A subroutine with a single exit point is a lot easier to maintain than one
>with several exit points.

Ok, I'll bite: why is a subroutine with multiple gotos to a single exit point
a "lot" easier to maintain than that same routine with multiple returns?

It isn't any easier to understand: the meaning of an early return
due to an error is well understood and controlled, just as the meaning of
"break" or "continue" is well understood with respect to loop termination.
In contrast, the meaning of "goto foobarexit" requires scanning ahead
to the definition of foobarexit to determine exactly what happens next,
even if you can guess from the label that this is some sort of exit
processing.  If you want to know if a given routine has multiple exit
conditions, it's just as easy to scan backwards for "return" as it
is to scan for "goto foobarexit."  The only maintenance tasks that I
can see that get any easier are inserting special-purpose cleanup
code that must run before a given function returns (regardless of
why it is returning), or changing the return type of a function to
a type that existing return values won't get automatically coerced to.

I can't see that either of these comes up often enough to warrant
claiming great advantages for the "single goto" solution.  In the case of
the cleanup code, it seems more likely that the type of cleanup will depend
on the reason for termination (as it did in the original example, where
you thought the goto solution to multiple labels was inappropriate).

The "single goto" solution isn't horrible; I just don't see the great
advantages claimed for it.  On balance, I prefer multiple returns
when a simple return is appropriate, just because it is slightly more
self-documenting.  I have no problems with a goto when complicated
cleanup must be done, but I find this case to be rare.

So what maintenance issues come up often enough in your environment that
you find the "single goto" solution far superior to multiple returns?
--



Mon, 24 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:


>[snip]
>:  DON'T use a goto unless it's the only solution to the problem.
>:  You have many alternatives to a goto in your above code.

>Wrong.  'goto' will never be the only solution.  When the 'goto'
>solution is more elegant than the other choices (which is entirely
>possible), use 'goto'.

These are guidelines, not hard and fast rules. But, you're right, if this
were true, then the situation I presented of breaking out of a nested loop
would break this since there is an alternative. I probably should have
worded that differently. Your response is better.

Quote:
>:  A subroutine should have at most one label.

>Arbitrary number.  Does a subroutine with exactly *two* labels
>automatically and magically become unreadable?

>:  All goto's should be above that label in the code.

>Above?  You mean all 'goto's should be forward jumps?  Why?

The reason for these two is to develop a mindset. If I stray from these, I
want the thought "Am I f***ing up here!" in my head. Using goto's
can lead to a lazy attitude, which can lead to abuse. I currently maintain
a huge set of COBOL code that is littered with goto's in every direction.
Believe me, it's a {*filter*} to make changes to this code and when I jump into
it, it becomes real easy to say f*** it and do the same thing myself. If I
let this attitude creep into my C programming I'd be a dead man. I
advocate the judicious use of goto's. If I had to list one hard and fast
rule it would be, keep the goto's and their labels in the same block of
execution. Have a little mercy on yourself and/or the person following you
in the future.

Quote:
>That's the point against using 'goto's.  Realize however that a
>good engineer is usually smarter than blind guidelines.  The
>rules you raised have obvious drawbacks.  Personally, the rule
>I impose upon myself is: "If you use a 'goto', you better have
>a damn good reason for it and be prepared to explain why all
>other constructs make the program uglier."

Well said!

-John



Mon, 24 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:


>[snip]
>:  DON'T use a goto unless it's the only solution to the problem.
>:  You have many alternatives to a goto in your above code.
>Wrong.  'goto' will never be the only solution.  When the 'goto'
>solution is more elegant than the other choices (which is entirely
>possible), use 'goto'.

I agree that GOTO wo;; mever be the only solution.  One can simulate any
GOTO language in a GOTO-less language.  And what is a switch or case
statement other than a generalization of the fortran computed GOTO?
BTW, I have come up with a situation where the analog of the Fortran
assigned GOTO (in some places  ASSIGN LOC TO K; in others GOTO K)
would be quite useful in reducing transfers.

Quote:
>:  A subroutine should have at most one label.
>Arbitrary number.  Does a subroutine with exactly *two* labels
>automatically and magically become unreadable?

I would make it a block.  I have an extremely natural example
of a block where there should be six entry labels.

Many, if not most, mathematical function libraries now have two entries
in the sincos routine.  I would expect a Jacobian elliptic function
routine to have at least six.

Quote:
>:  All goto's should be above that label in the code.
>Above?  You mean all 'goto's should be forward jumps?  Why?
>:  The label should be in the same code block or at a more outer
>:  nesting level than the goto itself.
>: Your code could be easily reorganized to not use a goto.
>That's the point against using 'goto's.  Realize however that a
>good engineer is usually smarter than blind guidelines.  The
>rules you raised have obvious drawbacks.  Personally, the rule
>I impose upon myself is: "If you use a 'goto', you better have
>a damn good reason for it and be prepared to explain why all
>other constructs make the program uglier."

One of the most important reasons is that the code will run faster.
Sometimes the main cost of the algorithm consistes in processing
the transfers and conditional transfers.  Storing and loading
vlaues which are only needed to indicate where to transfer, and
the use of case or switch statements, with their overhead, can
often be replaced by the use of simple goto instructions.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399



Tue, 25 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

>If a routine needs to perform some cleanup before returning
>and there may be occasions where an early RETURN is required
>(e.g. errors), then GO TO to transfer to a single clean-up-
>and-return code block is neater than multiple copies of said
>block.  Of course if the clean-up is complex, it would warrant
>being a separate (internal?) procedure.

What would be better here would be a language that provided proper
structure -- ie, an Exit block that would always be executed when the
associated block is exited, whether by RETURN, GOTO, or exception.  I
once kludged this up with a macro processor and it did wonders for
recovery-intense code -- made for much cleaner, more structured code.
(Ran like a pig, but that was mostly due to the kludgy implementation.
And where we used it performance wasn't that much of an issue.)

Dan Hicks
http://www.millcomm.com/~danhicks/



Fri, 28 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

> This is goto-free and I think equally clear:>>>------------------------------------------------------------------------------
>   HEV    hev1, hev2, hev3;     /* Event semaphores */
>   HMTX   hmtx;                 /* Mutex semaphore  */
>   void  *ptr;
>   if DosCreateEventSem(0, &hev1, 0, FALSE) then do;
>    if DosCreateEventSem(0, &hev2, 0, FALSE) then do;
>     if DosCreateEventSem(0, &hev3, 0, FALSE) then do;
>      if DosCreateMutexSem(0, &hmtx, 0, FALSE) then do;
>       ptr = malloc(SOME_SIZE)
>       if ptr<>NULL then do;
>          /* Do some stuff here */
>          return TRUE; /* We did okay */ end;
>       DosCloseMutexSem(hmtx);  end;
>      DosCloseEventSem(hev3);  end;
>     DosCloseEventSem(hev2);  end;
>    DosCloseEventSem(hev1);  end;
>   return FALSE;

> And I would assert my code is (1) a lot more PL/1-like and
> (2) a lot easier to understand.

1. I assume you have #define'd "do" and "end" as "{" and "}".
How do you encode "do {...} while(...);" ?
2. The extra semi-colons after each do & end don't achieve anything.
3. What does "<>" mean in C ?

Otherwise, this is one example where you can remove goto's without loss
of speed and improve clarity.
This doesn't mean you should never use goto's.

--
Andrew Dalgleish
Senior Software Engineer
Axon Research, Pty Ltd
6 Wallace Ave
Toorak, VIC
3142
AUSTRALIA
Tel:    +61-3-9826-5538
Fax:    +61-3-9824-0083



Sat, 29 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:
>> And I would assert my code is (1) a lot more PL/1-like and
>> (2) a lot easier to understand.

>1. I assume you have #define'd "do" and "end" as "{" and "}".
>How do you encode "do {...} while(...);" ?
>2. The extra semi-colons after each do & end don't achieve anything.
>3. What does "<>" mean in C ?

And I would assert my code is a lot more PL/I like.

Quote:

>Otherwise, this is one example where you can remove goto's without loss
>of speed and improve clarity.
>This doesn't mean you should never use goto's.

But it was presented as a case where gotos were better.  Sigh.

An assembler maven walked into a bar and asked the bartender: "Do you want
to hear a PL/I programmer joke?"

The bartender was a big fellow with a baseball bat behind the bar which he
used for crowd control.  "Hey, wait a minute!" the bartender said.  "I am a
PL/I programmer.  And see that fellow over at the pool table?  He's a PL/I
programmer too."  The maven glanced over towards the table and saw a
six-foot-six refugee from the Ohio State offensive line wearing a XXXXL
tee shirt that was a few sizes too small.  "And check out Fred over by the
juke box, he's a PL/I programmer himself".   The visitor looked over to the
juke box and Fred wearing leathers and had a chain{*filter*} from his belt.

"Now do you still want to tell a PL/I programmer joke?" the bartender asked.

"Naw," the visitor replied.  "I don't want to have to explain it three times."



Sun, 30 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

> In 1968, Edsger Dijkstra wrote a letter to the _Communications_
> _of_the_ACM_ titled "Go To Statement Considered Harmful".  This
> paper has since been widely reprinted.  In 1974, Donald Knuth
> wrote a paper for _Computing_Surveys_ titled "Structured
> Programming with GOTO Statements".  This paper has also been
> widely reprinted.  These were not the first nor the only papers
> written on this subject, but to my mind, they should have been
> the last needed.  Anyone who argues this issue should first
> be required to prove he (or she) has read both these papers.
> Anyone who hasn't read these papers should be ignored out
> of hand.

> That being said, I'll go ahead and add my $0.02 to the mix.

> I actually use GOTOs all the time.  Except for the "hello world"
> program, my programs tend to have thousands of GOTO's.  For example,
> an IF without a ELSE clause has one conditional GOTO, with an ELSE
> there's both a conditional and an unconditional branch.  A WHILE
> loop has both conditional and unconditional branches too.

> Now this is both trivially obvious and rather silly.  But it still
> raises the question of why CASE, IF(ELSE), WHILE(FOR, etc.), and
> procedure calls are the only branches anointed as "structured".
> It wasn't always so.  Though these were the constructs mentioned in
> Dijkstra's letter on the subject, there was no suggestion that these
> were the *ONLY* appropriate constructs.

< .... many lines deleted .... >

- Show quoted text -

Quote:
> Well, there's a lot more to talk about GOTOs (like exception handling!),
> but this is enough for one article.  The bottom line is that automatic
> rejection of GOTOs for religious reasons loses sight of the real issues
> which led to the controversy and often can lead to unfair disregard for
> techniques which are perfectly sound.  New kinds of GOTOs slowly reach
> into the "structured" pantheon, but only very slowly (and perhaps correctly
> so).  Complete elimination of GOTOs from available languages would stop
> this useful evolution entirely.  In any case, people should not be so quick
> to condemn *all* GOTOs out of hand.  As Dijkstra himself pointed out:

>       Please don't fall into the trap of believing that I am terribly
>       dogmatical about it.  I have a feeling that others are making a
>       religion out of it, as if the conceptual problems of programming
>       could be solved by a single trick, by a simple form of coding
>       discipline!
>                                       - E.W. Dijkstra

In the APL world it has often been seen as an inferior style of using
GOTO or even LOOPS at all.

In most instances they are not needed. I might add that in ALL cases
you could avoid GOTOs and LOOPs if you really put your mind to it.

In the most advanced of languages, J , there were no GOTOs or LOOPs in
the beginning. They have been introduced in the most recent versions
of J and are now a well appreciated part of J.

In the most recent versions of J there are now several Control
Structures. Not needed according to the purist but I personally
find them easy to use and saves me the hassle of being too clever
all the time.

You have:

if. ... do. ... end.
if. ... do. ... else. end.
if. ... do. ... elseif. ... do. ... elseif. .. .. .. end.
try. ... catch. ... end.
while. ... do. ... end.
whilst. ... do. ... end.

there are even more conventional Control Words:

break.
continue.
goto_name.
label_name.
return.

Using these kind of structures can simplify the job of initial
solving a problem of program flow while you are solving a new kind
of challenge.

Once you have the system solved I find I can usually go into the
system and remove the control structures.

One which is quite handy is the
try. ... catch. ... end.
But only until you have the system under control then it is actually
worse. In the catch part you have to be clever to report the error
that occurred. Unless you do not care about the error and always want
to do certain action if the try part does not work and given correct
situation it should.

--
/Gosi

562 5441
http://www.jsoftware.com



Mon, 31 Aug 1998 03:00:00 GMT  
 GOTO controversy

Quote:

>1. I assume you have #define'd "do" and "end" as "{" and "}".
>How do you encode "do {...} while(...);" ?
>2. The extra semi-colons after each do & end don't achieve anything.
>3. What does "<>" mean in C ?

This thread is being posted to comp.lang.misc and comp.lang.pl1 as well as
comp.lang.c, so you should not assume that the example code was written in C
syntax.


http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html



Mon, 31 Aug 1998 03:00:00 GMT  
 
 [ 42 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. GOTO controversy

2. GOTO controversy

3. GOTO controversy

4. To GOTO or not GOTO

5. Topspeed File Driver (Continuing Controversy)

6. Case sensitivity variable controversy

7. Floating Point Controversy?

8. THEN controversy

9. Visual C++ controversy

10. High-level languages, large projects, GNOME and the .NET controversy

11. Module Packages - package-search-strategy controversy

12. Linda controversy

 

 
Powered by phpBB® Forum Software