Software Development

Webcomic: Why you should never use the GOTO command


Click to view original comic

Software development best practices tend to get discarded when you're on deadline -- or just lazy -- but xkcd warns us of the dangers of a hastily employed GOTO command (via a Jurassic metaphor). If only it really were this hazardous to write crappy code, we wouldn't have so much crapware floating around.

About

Jay Garmon has a vast and terrifying knowledge of all things obscure, obtuse, and irrelevant. One day, he hopes to write science fiction, but for now he'll settle for something stranger -- amusing and abusing IT pros. Read his full profile. You can a...

11 comments
traderawb
traderawb

Back in the days of BASIC, I wrote mainly in spagetti code which is still working today. But I rarely have to trouble shoot it any more. Wouldn't want to. Hope I never have to. This in the days before top down Pascal and structured programming came along. Don't remember any dinosaurs though, except for myself; that is.

Nodisalsi
Nodisalsi

Didn't this happen to the coder in Crichton's Jurassic Park after he wrote his "Rabbit" routine? LOL

mszs2
mszs2

Besides that some languages aren't powerful enough to get around it without like old BASIC, commands like return and break are hidden GOTO's IMHO.

gadjet
gadjet

...for every computer I crashed back in the early days of basic. All because of a bad goto routine I'd be extremely rich!!! And I wouldn't be sitting here... I could be on a beach somewhere and have someone else crash the computers for me ....

Wayne M.
Wayne M.

Changes in a programs flow are a necessary part of programming. The reason not to use GOTO statements is that they are unstructured in nature - they can be used well or poorly. Modern languages have added commands that implement GOTOs in a structured manner and these commands should be used in preference to GOTO. Only in cases where the language does not support a needed construct should one look at using GOTO instead. In most current generation languages one should never need to use GOTO. In languages lacking exception handling (C and VB come to mind), GOTO was often used for error handling. For a more measured approach showing why the GOTO fix (apparently in lieu of restructuring the logic to use a standard branch operation) hinted at by the comic, refer to Cyclomatic Comlexity Measurement. This provides a measure of code complexity based upon program branching and will typically show a bad result where an aribtrary GOTO is used in place of structured flow control operations.

Tony Hopkinson
Tony Hopkinson

jump to a point in the code fixed by it's structure. No label is the difference. Saying that break in a loop says bad design to me... in a switch statement, bad semantics..

elizabetsno
elizabetsno

return and break are certainly a form of GOTO, but they are predictable. Anyone reading code using these should be able to predict the result of them by reading a limited bit of the code. Raw GOTO's can work in the short run, but since they can go anywhere, any later change can cause them to do unpredictable things.

Freebird54
Freebird54

I never minded the GOTO. It sure could be misused though! Any language that puts out a jmp code in the ML is doing a goto anyway - so why worry?? Select case case 1 goto here case 2 goto there case 3 goto everywhere end case

Mikiel
Mikiel

Luckily all the high level languages I've seen recently go more like Select case case 1: do this case 2: do that case 3: do something else If a language has goto's in the ML, that's fine with me. The trouble begins when the code that's read by the programmer has goto's. I remember programming in Basic on the Commodore 64. The only way to branch was via goto (or gosub) some line number (like the scary example Tony Hopkinson presents). Very difficult to maintain/debug.

Tony Hopkinson
Tony Hopkinson

including me probably 150 If A < 1 THEN GOTO 6377 :D I was apalled when I saw C# had it in the switch statement, it's become my goal in life never to design anything where I have to implement that.