GOTO has never gone (away)
In the late sixties, Edsger Dijkstra wrote an article about the use of the goto statement, highlighting how it encouraged the spread of a unstructured code style often hard to understand: the so called spaghetti code. The proposed measure was the removal of the goto statement from all high-level programming languages in favour of the use of structured control flow constructs like if/else, while, repeat, etc.
Nowadays almost nobody uses anymore the goto statement when writing programs with high-level languages, although this statement is still provided by languages such as C/C++, C#, PHP.
This could be considered a good result. Unfortunately, the spaghetti code problem does not depend on the specific statement, but mainly on the developer mindset. Although it is well established that the idea of using the goto statement is “unseemly”, the tendency to write jumping code has not disappeared.
OK, goto is evil, but since in many programming languages there are statements like break, continue, exit, return, what’s the harm in using them? And so the goto statement comes into play again disguised as a legal statement, a masked goto, as in the following JavaScript code:
What’s wrong with this code block? Nothing. From a functional point of view it is correct. It does exactly what it should do: it truncates a string to the specified number of characters (10 characters, unless specified) and adds an ellipsis at the end.
However, this code does not make me crazy for its readability. It gives me the impression of programming by attempts, without an organized and consistent reasoning. It seems to follow a sort of strategy like “now that I got an acceptable result, let me leave before getting mixed up in a flow that I can’t control.”
This is an example of code barely written for the machine, not for humans.
In this specific case, I prefer an approach whereby a function or a code block has a single point of entry and must have a single exit point. Readers of the code must be able to understand in a linear manner what is returned without having to search through the statements that make up the body of the function.
The use of masked gotos is a sign that the demonization and removal of a construct or a statement from a language is often not enough to prevent its misuse. The way of thinking of the developer can dig it out in different ways. In my view, code that uses masked gotos shows the developer’s hesitancy against the proposed solution. It’s a bit like a babbling, a sputter without security, without a solid reasoning and its reading is not easy.
The use of masked gotos should be a very rare exception, and the development tools should discourage their use in different ways. Unfortunately, some of the most commonly used programming languages may suggest that in reality there is no harm in using a masked goto. For example, the switch statement in languages like C/C++, C#, Java, JavaScript, etc. involves the use of break to avoid the fallthrough, i.e. continuing to the statements associated with the next case block:
I always wondered why do we still carry this legacy derived from C? Why in the definition of modern languages like Java and C# they did not choose to follow the Pascal family approach, where only the selected case block is executed? It seems a more consistent style for a structured language. The presence of the break statement inside the switch construct could subconsciously justify some developer in using masked gotos as perfectly legitimate.
In conclusion, I still consider valid Dijkstra’s argumentation regarding the use of goto statement (masked or not), but I think that the problem is not in the statement itself, but in how the developer expresses his reasoning. Too often it is a dialogue with the machine rather than a human reader.
By the way, the following is a more readable version (in my opinion) of the code in the previous example:
