Page 1 of 2
What is it about the Goto that attracts velociraptors? Once you know, dino attack is the least thing on your mind!
More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language.
This article was prompted by an xkcd cartoon on the front page of I Programmer.
It raised the question:
"What is so bad about the Goto - apart from being
attacked by a velociraptor?"
So here is the standard and undisputed story of the Goto, Spaghetti and the quest for clean, pure, code.
The flow of control graph
When you first learn to program the big breakthrough is when you realise that there is such a thing as "the flow of control" and you begin to master it.
Well perhaps master is too strong a word but you do get comfortable with the idea and eventually it seems natural.
Acquiring the concept of "flow of control" is what makes the difference between a programmer and a non-programmer and if you think it's trivial and obvious then this is simply because you made the transition some time ago.
If you want a demonstration that it is far from obvious just try to teach programming to someone who hasn't encountered the idea before in any other shape or form. You can't help but pity their undeveloped sense of what follows what and how they ever manage to follow or give any coherent instructions is a mystery. But they do, nearly always, make the transition and acquire the core concept of programming.
The flow of control is simply the order that instructions can be executed in. It normally follows a simple top to bottom and occasionally left to right flow in a simple list of instructions but it also splits into two or more paths in the case of conditionals and it goes round in small circles for loops of all kinds. However even this description presupposes a lot of knowledge and it took time to work out.
If you think all of the paths through a program then you have in your mind the "flow of control graph". Think of it as a set of connected lines showing the possible routes through a program.
In the early days of computing we wrote in machine code or assembler and you can't have complex instructions in machine code. Machines run programs using the default one-after another flow of control until they hit a branch or jump instruction when they are directed to start the default flow of control at some other instruction somewhere else in the program. In machine code this is all there is. You use the jump instruction to create conditional and iterated code.
The conditional either takes the jump or doesn't depending on the value in some register and the iteration builds a loop by jumping back to an earlier point in the program's flow of control.
Notice that we already have a sort of rule - jump backs make loops, jump forwards make conditionals.
Now we come to the problem.
Early programmers didn't have a clue what they were doing. It was hard enough to get your program and data to fit into the tiny amounts of memory - they simply didn't have the luxury to step back and philosophise about how best to program. In other words methodology came low on the list.
What the environment encouraged was economy of expression. If you could see a way of reusing a bit of code then you jumped to it. Programs in general were full of jumps all over the place with no particular structure or design. As a result the flow of control graph looked like spaghetti.
To boldly Goto...
But - this generally didn't matter because code was handcrafted and used and modified by the person who wrote it. spaghetti code was ok - not good but ok.
Then high-level languages were invented - Fortran introduced the Goto. In fact at that time high level languages tended to use the underlying machine code as their model for there instructions and many of the control statements in Fortran were simply machine code instructions renamed - the jump became a Goto.
The problem is that high-level languages were used by lots of people and teams of programmers started to work on projects for the first time. The Goto was used in the way that it was in the machine code days. High level programmers generally Goto-ed all over the code and created huge blobs of spaghetti code. Working in teams and having to come back to work on their old programs the spaghetti flow of control graphs made the code difficult to understand and difficult to debug.