Re: GOTO considered necessary

[adam@irvine.com (Adam Beneschan)]

yeung@reed.edu (Woodrow Yeung) writes:
 >
 >> THere are many obvious examples, one of the most familiar is to provide
 >> a continue facility for loops
 >> 
 >>     while ..... loop
 >>        ...
 >>        <<Continue>>
 >>     end loop;
 >
 >Oh dear, I have to disagree with this on two levels.  It's far cleaner to
 >have a continue control structure than using a goto to implement it. . . .

I have to disagree.  When I used to program in C, I made a rule for
myself not to use the "continue" statement.  The reason: When I did
use it in a loop, it worked fine, but then I'd find I had to make a
modification that required that some extra actions to be taken at the
end of each loop, before going to the next iteration.  So I'd add
those changes just before the closing }.  All of a sudden, "continue"
no longer worked; if I had any continue's up in the remainder of the
loop code, I would have to search for them so that I could replace
them with something else, and if I forgot, oops, I just put a bug into
the program.  

At least if you have a goto-label construct:

    while ..... loop
       ...
       <<Continue>>
    end loop;

Now, when you have to add something just before "end loop", at least
the presence of a label alerts you to the fact that something might be
jumping there in order to perform a "continue"; now, you have to
decide whether to add your code after or before the label.  But you're
less likely to make a modification that would screw things up.  At
least, that's my experience.

Sure, one could come up with a case where "break" (or "exit", in Ada)
has the same problem, but my experience is that problems like this
don't occur--or rarely occur--with exit constructs; while they seem to
be more frequent with "continue".  I don't know why "continue" should
be considered cleaner than an appropriate GOTO construct; I don't know
what definition of cleanliness would make this so, except for one that
proclaims that GOTO's are inherently unclean just because they are.  I
had to get over this attitude when programming in COBOL 66.  [I think
I got the language version right this time.  :)]

(BTW, I'm not likely to use *either* construct: boolean variables seem
to work better for me.)

                                -- Adam