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.
RELATED STORIES
Eliminate The Legitimate Use Of GOTO
New for RPG in IBM i 7.2 and 7.3 – ON-EXIT section to be run whenever a procedure ends
I always just coded an exit subroutine, and executed it in place of all the returns.
That is a clever technique, Justin, and it never occurred to me. Thanks for sharing it with the rest of us.
There is NEVER a reason to use GOTO or TAG in 2017. NEVER. Several languages don’t even have GOTO such as Java, C#, many others…
Ted, the GOTO flap was actually tongue-in-cheek. The topic took on a life of its own and became a rally cry for those whose proudest accomplishment was to deliver a huge monolithic program without a single GOTO. Of course, trying to understand that logic was a bear.
I’m with you WRT IBM’s petulance on free-forming GOTO and TAG–IBM’s failure to address these unsophisticated op codes has likely slowed adoption of free-form RPG. Many users told me they didn’t think IBM was serious about free-form because this.
I had many interactive programs using GOTO to control program navigation (I supported a help screen and many command key functions) and finally wrote a program to strip out the GOTO’s. IMO, the resulting programs are harder to follow unless your source is carefully and consistently indented, which means you’re using RDi (and if not, why?). If you use GOTO for calculation loops, you’re not a programmer or even a good coder–you’re a very bad coder.
I believe a “prosper program” has a single entry point and a single exit point. So, peppering your code with RETURN’s may be convenient but it’s not a best practice. Finally, IBM has addressed the issue!
My solution has been to put my exit code in a subroutine within the procedure. It appears to work fine.
-reeve
Goto occasionally has a use when you have very very old code that has been hacked to pieces. Often converted from OPM
Remember, most of developers time is hacking old code, not writing shiny new programs.
It’s annoying when you’re converting old code, but the net effect in my opinion is positive.
Your justification for using GOTO when you do is perfectly correct. It is good.
The issue for your code specifically is when others have occasion to eyeball your code.
But there is a bigger scope involved for compiler makers. The removal of GOTO from the clutches of lazy programmers (meaning not you) that abuse this rarely useful operation code forces relieves you and me from dealing with spaghetti that is too tangled up to parse within a reasonable time, like say, a year.
🙂