GOTO structures in program code

When I started to code programs, IBM mainframe memory had become large enough to accommodate almost any bread-and-butter program, which basically were read X files match them and print a paper report or read two files match them and update one file with the contents of the other.  This meant you could afford the luxury to structure programs with other goals than saving memory.  In COBOL the first programming language I learned,  there were two instructions particularly suitable for creating memory saving code, GOTO and ALTER.

The first of those two instructions GOTO was used to branch freely anywhere in the code. A liberate use of GOTO easily create code that gives an impression of a full spaghetti bowl. You do not have to be a brain surgeon to understand a spaghetti bowl of code can be hard to debug.

The latter of these two instructions ALTER was used to change GOTO statement on the fly. Yes ;  you could make a GOTO sectionA  statement in a  program go to sectionB  by issuing an ALTER sectionA TO PROCEED TO sectionB .   If you have spent some hours with a bowl full of spaghetti code and finally starting to make some sense out of it, then you find some devilish ALTER statements (ALTER was always written in the last piece of code you looked at).  Even a bicycle repairman understand such code is a challenge to debug. The only help you had was a paper printout of the program and a dump which didn’t told you a thing. (NO; very few programmers not versed in assembler understand dumps). You used pens, paper clips and fingers to bookmark the code, and then you saw the feared ALTER… In the old days the programmers had a large active vocabulary of colorful words.

When I was a computer operator I developed a contempt for programmers, they were a miserable bunch that tried to make you prioritize their test job , by everything from sweet talking to  aggressive threats. Of course you place their jobs at the bottom of the work queue. It was only later when I become  a COBOL programmer I understood why they behaved the way they did. Debugging GOTOs and ALTERs do things to you personality, bad things.

But when I came along things had start chang e , I structured my first program with the help of Jackson structured programming method.  I used novel structured branching like DO WHILE…END. We abolished ALTER altogether and used GOTO sparsely. The code quality got much better and the productivity sky rocketed.

Today people do not seem to know why GOTO can be bad in code, people seem to think the instruction GOTO is bad. But rightly used GOTO can be a blessing. It is frequent use of unstructured GOTO that makes program both error-prone and hard to debug. Programs are code models and abstractions of the real world, and the real world is not restricted to FOR EACH or DO WHILE structures, sometimes the free GOTO instruction is just the right instruction to use.

I end this post with an extract of the first GOTO I written in thirteen years.

 

Update

Yesterday i was thinking why not solve the example above with recursion? That is more elegant. I always have had a preference for recursion, it reminds me as a child standing in front of a mirror with another mirror in my hand staring into eternity. Recursion is beautiful.

This is PHP code, and I added this GOTO as part of trying it out when the instruction was added into the language. Also here the GOTO does a better job than a recursive call. And PHP lacks tail call recursion optimization , which means you should always be cautious with recursive calls. In this case it does not matter though since we only go to RestartJob  once, If the guard  routine fails a second time we fall through and the job fails. In this case GOTO does a better job.