Many programmers consider using the GoTo construct bad practice because they think it leads to something called SpaghettiCode. This was true at one time, and led to the declaration GotoConsideredHarmful.

The solution to the GoToProblem is the ComeFrom command (if you like INTERCAL) or the GotoComeFromPair.

Another solution is TailCallOptimization.  GoTo creates unreadable SpaghettiCode because the communication between calling code and called code must be via shared state.  The reader must try to match up assignments before the jump with variable uses after the target of the jump.  With TailCallOptimization, the called code receives information as named parameters, explicitly sent by the caller and explicitly received and named by the callee.

----
The GoToProblem is also a very good example of what happens when you blindly follow 'rules' without thinking. The first sentence of the GoTo page is a very nice statement I'd like to see more often on those one thousand three hundred seventy-two-point-six XxxConsideredHarmful pages.

----
Goto is not a problem. The problem is many people who use it.

''Smoking isn't bad for you if you do it occasionally... the problem is the people who...''

Actually smoking is bad, whether or not you smoke. Because it can affect other people. ''(But GoTo can affect other people working on the same code as well!)'' The problem of Goto is if you use it too much. A good program language should have goto as well as other structured programming, so much that you should hardly ever need goto command.
----
CategoryBranchingAndFlow