Re: GOTO Considered ...

[adam@irvine.com (Adam Beneschan)]

In article <dewar.866202982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 >I think a lot of the difficulty is that many programmers don't like
 >the look of a GOTO at the syntactic level. What one should be
 >allergic to is the misuse of goto's, but that of course requires a
 >more sophisticated level of judgment.  Much easier to understand a
 >simple rule like "goto's are horrible, period".
 >
 >I once consulted for a big aerospace company on some big COBOL code,
 >which was very hard to read. In one place there was something like:
 >
 >    PERFORM CLOSE-FILES.
 >
 >and I had a very hard time understanding what could happen when control
 >returned from the PERFORM (which for the purposes of this discussion can 
 >be considered comparable to a procedure call).
 >
 >After following the logic down ten levels, I found a STOP RUN statement,
 >so in fact the upper nine levels of PERFORM never did return at all.
 >
 >I commented that the code would be MUCH clearer if those PERFORM statements
 >were replaced by GOTO statements. The response
 >
 >"Oh, but we aren't allowed to use GOTO statements"

Sigh . . . I think anyone who institutes a no-GOTO rule in a COBOL
environment ought to have their head examined.  I was working as a
COBOL programmer about 20 years ago, when "structured programming" was
just coming into vogue, and I tried to write all my COBOL programs
without using any GOTO's.  I finally gave up.  COBOL doesn't have any
loop constructs---you have to put the body of the loop somewhere else
and do a PERFORM UNTIL or something.  Also, COBOL doesn't have the
begin..end or if..end if constructs that languages like Algol and Ada
have, so that something like

      if condition_1 then
          statement_1;
          statement_2;
          if condition_2 then
              statement_3;
          end if;
          statement_4;
      end if;

could not be coded directly in COBOL, without using a PERFORM.  While
I could accomplish GOTO-less programming by using lots of PERFORMS,
the PERFORM'ed "procedures" didn't really match what a procedure
should be, a cohesive module that performs a specific task on given
inputs and outputs.  These "procedures" were just there to get around
a lame language syntax.  What I found was that using this many
PERFORMS actually detracted from readability, and that I could make my
code more readable to use GOTO's for control structures such as these,
while keeping my "procedures" small and with well-defined purposes,
and keeping to the "structured design" principles that Yourdon had
written about.  (And, of course, avoiding mutant constructs like ALTER
and like overlapping procedures that you could call in different ways
by changing the names of the paragraphs you PERFORM'ed THRU.)

Well, enough nostalgia for one day . . . (P.S. If COBOL has been
modified to provide these control structures it used to lack, I'll
retract my initial statement.)

                                -- Adam