The goal of any good code is to be reliable, readable, and safe. Pioneers of computer science put a lot of effort to enhance programming languages to the levels we see now. Sometimes their explorations were breakthrough, sometimes radical. But like any field of technology computer science is constantly evolving. And what was once “considered harmful”, now is a subject for an open discussion.
There is almost a religious war against using Goto in programming. Why was it considered harmful? Is it still banned from active use now? Are there useful exceptions? Let’s try to find out. But first let’s understand what Goto is.
WHAT IS GOTO?
Goto (goto, GoTo, GOTO, GO TO) is a basic statement common for a nig number of computer languages. It has a simple and understandable function: a one-way transfer of control to another code line. Control destinations are normally identified with labels. Nevertheless, there are some traditional languages that use line numbers to identify Goto destinations. As far as machine understands it, a Goto is a sort of branch or jump statement, sometimes accompanied by a stack adjustment. There are also many programming languages that do not support Goto at all.
Goto statement is famous for a loud scientific dispute on its use at the dawn of computer technology. Back then Goto was quite common, not until the invention of structured programming in the 1960s and 1970s when it saw a significant decline in popularity. Though it is still used today (to a limited extent), the debates on its relevance still excite the academic and professional software community. The main argument against Goto was that code using this statement is more difficult to read and harder to understand. They call it Spaghetti code.
WHAT IS SPAGHETTI CODE?
Code that uses too many Goto statements rather than structured programming constructs is often called spaghetti code. Why spaghetti?
Because the complex and tangled control structure of such a code can be associated with a bowl of spaghetti, all twisted and tangled.
In 1980 the ‘spaghetti code’ term became official, when the United States National Bureau of Standards have used it in one of its publications to describe older programs having issues with "fragmented and scattered files".
THE RISE OF GOTO DISPUTE
Time to meet Edsger W. Dijkstra, the iconic opponent of Goto who wrote a famous letter called "Goto Statement Considered Harmful" (1968). In that text Dijkstra had a radical claim that unrestricted Goto usage should be eliminated from higher-level languages. He blamed Goto for obscuring the tasks of analyzing and verifying the programs correctness (those involving loops in particular).
Of course, there were some alternative points of view. Donald Knuth's in his “Structured Programming with go to Statements” has analyzed several programming tasks and found out that in some of them Goto is the best solution to use. In their work “The C Programming Language”, Brian Kernighan and Dennis Ritchie stated that Goto is "infinitely abusable", but also suggested its use in end-of-function error handlers and multi-level breaks from loops.
There were other programmers, like Linux kernel designer Linus Torvalds or software engineer Steve McConnell, objecting to Dijkstra's radical opinion. They argued that Goto can be a helpful language construct, optimizing speed, size and code transparency of the program. As of 2013, according to computer science professor John Regehr there were 100,000 cases of Goto usage in the Linux kernel.
SO, SHOULD WE ALLOW GOTO?
It looks like everyone is on the same page regarding that Goto should never be used to jumping up a branch to an earlier point. Same “no-no" goes for branching into a deeper level of nesting.
However, branching DOWN in the function and OUT to an outer level of nesting might work for you as a powerful tool. For instance, a one Goto statement can be implemented to escape from two or more levels of nesting. And this is not what typically can be done with a single break or continue. To do the same without Goto, you might face the need to set a flag variable in the inner block and check it in each outer block.
OR SHOULD WE FINALLY BAN GOTO?
Some authors claim that the use of Goto “decreases readability” and “increases potential for bugs”.
Another opinion behind the ban is that Goto alternates the natural program flow. It looks like the program encounters a fatal error and needs to be aborted immediately. But when, instead of aborting, you write a Goto statement to jump to the next segment of the function, it can lead the whole application to failure or a data loss.
IN A NUTSHELL
At the end of the day, there is always an engineer (or a team) responsible for the successful design. And such professionals should possess a wide range of tools with a clear risk-reward understanding of each of them.
Today's software engineering community is inclined to think that Goto is a high-risk, low reward tool. However, radical banning might have its cost. And even if there are only a few extraordinary cases where Goto is a better solution – we should keep it.
