Guru: Eliminate The Legitimate Use Of GOTO, Take Two
February 27, 2017 Ted Holt
I was annoyed that IBM chose not to support GOTO and TAG in free-form RPG calculations. I rarely used those opcodes, but when I did, it was in disciplined situations when nothing else would do. Besides, I didn’t want to be treated like a baby. Now it’s a non-issue. IBM finally provided an alternative to the last legitimate use of GOTO.
Almost five years ago, I wrote about a situation that I come across from time to time, namely the need to execute a clean-up routine before exiting an RPG subprocedure. Since nothing forbids a subprocedure to have multiple exit points, it is common to see more than one RETURN operation within a subprocedure. The problem is that RETURN immediately leaves the subprocedure without executing the clean-up code. In those cases, I replace RETURN with a GOTO that branches to the clean-up routine.
Until now. IBM recently added a feature that allows us to specify code that needs to run upon exit from a subprocedure. GOTO is gone from my RPG code!
Look at this comparison of part of the code with GOTO (on the left) and the new code without GOTO (on the right).
To me that’s serious progress, but maybe I get too excited over little things.
It’s been almost 50 years since Edsger Dijkstra alerted the computing world to the intrinsic harm in GOTO. Yet even today, programmers whose motto seems to be, “When in doubt, GOTO,” are paid to sling code.
Why do I hate GOTO so much? It’s a case of sour grapes. I’m not smart enough to understand programs that use it.