I try to be not dogmatic about GOTO statements,
in fact, I am coding COBOL in my money (everyday) job, and there are
lots of GO TOs around;
I try to remove them, when I do larger refactoring, but if not, I leave
them untouched.
But now for another GOTO story.
When I started my Stanford Pascal compiler adventure in 2011, the first
compiler pass (PASCAL1)
had around 50 GOTO statements in it (in fact: 50 numeric labels which
are targets of GOTOs in Pascal;
in Pascal, BTW, GOTOs are allowed, but they are sort of uncomfortable;
you need a label declaration for them, not only the GOTO statement and
the target label -
because the label is local to a block, the label number may be reused in
different blocks).
The Stanford compiler, as many other Pascal compilers, is self-hosted,
that means, it is written in Stanford Pascal and compiled by itself.
The Stanford Pascal compiler pass 1 had 6.000 lines in 2011 ... with the
50 labels mentioned above
(well, this was the 1982 McGill version, to be honest).
One of my first extensions to Stanford Pascal was to add CONTINUE, BREAK
and RETURN statements
to it (semantics like in C). It turned out that almost all GOTOs were
used to implement the missing
statements CONTINUE, BREAK and RETURN using GOTOs. I then started (after
some time)
to remove the GOTOs by replacing them by the new statements, where this
was possible
without problems.
Today the compiler pass 1 has almost 25.000 lines. It only contains 7
GOTO statemens (I just checked it).
Because, see above, I am not dogmatic about GOTO, I will leave them, as
long as there is no need
to work on the procedures containing them.
The compiler story (including downloads) is here:
http://bernd-oppolzer.de/job9.htm
IMO, GOTOs (and the statements mentioned above) must be used with care.
If you don't use them right, nobody will be able to follow the logic in
your programs,
including yourself (after some time). Indentation is key, and meaningful
comments.
Kind regards
Bernd
Am 25.09.2022 um 13:51 schrieb David Crayford:
Another thing that makes me incredibly dubious about some of the
opinions in these videos is the hackneyed nonsense about "goto
considered harmful". The original paper was misunderstood in that all
goto statements are harmful and brainwashed a generation. Some of
these videos present a trivial example using goto and refactor it
using if/ifelse. In programming languages without scope based cleanup
goto is not harmful. In fact it's leads to clean code as the branch
direction is always descending to a cleanup block. Happily for me, the
young guys I work with writing systems level Metal/C code haven't been
seduced by this dogmatic BS. Good C code uses goto statements as
opposed to heavily nested or superfluously functionally decomposed
routines. The IBM Openj9 JVM C code is a case in point
https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/classsupport.c.
I challenge anybody to write better code without goto statements.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN