Is goto the root of all evil?
By Kai Seidler on Oct 06, 2009
As PHP 5.3 introduced the goto statement the old discussion about the evilness of goto came back to the surface of the Internet.
By coincidence I stumbled over this 6 years old discussion with Linus Torvalds about this topic. He's arguing goto makes the source code more readable, but read his thoughts and decide for yourself:
From: Linus Torvalds Subject: Re: any chance of 2.6.0-test\*? Date: Sun, 12 Jan 2003 12:22:26 -0800 (PST) On Sun, 12 Jan 2003, Rob Wilkens wrote: > > However, I have always been taught, and have always believed that > "goto"s are inherently evil. They are the creators of spaghetti code No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue. > (you start reading through the code to understand it (months or years > after its written), and suddenly you jump to somewhere totally > unrelated, and then jump somewhere else backwards, and it all gets ugly > quickly). This makes later debugging of code total hell. Any if-statement is a goto. As are all structured loops. And sometimes structure is good. When it's good, you should use it. And sometimes structure is _bad_, and gets into the way, and using a "goto" is just much clearer. For example, it is quite common to have conditionals THAT DO NOT NEST. In which case you have two possibilities - use goto, and be happy, since it doesn't enforce nesting This makes the code _more_ readable, since the code just does what the algorithm says it should do. - duplicate the code, and rewrite it in a nesting form so that you can use the structured jumps. This often makes the code much LESS readable, harder to maintain, and bigger. The Pascal language is a prime example of the latter problem. Because it doesn't have a "break" statement, loops in (traditional) Pascal end up often looking like total shit, because you have to add totally arbitrary logic to say "I'm done now". Linus
Read the full discussion at: http://kerneltrap.org/node/553/2131