Recently I've been reading up a lot on Computer Science, mostly on the topic of algorithms and computational complexity, and one oft repeated statement is "Don't use GOTO or you'll be mauled by raptors", or something to that effect. I feel that this is a great exaggeration - the raptors proved quite friendly.

For those who don't know what GOTO is, basically its a low-level (machine code) statement that makes a program continue from the point it describes.

Consider:

a = 0;

DoItAgain: //The GOTO label

a+=1;

if (a<5)

goto DoItAgain; //The GOTO statement

Here of course, one would use either a for or while loop if they wanted something like this. And, though that is undoubtedly the best thing to do in this case, realize that every loop is essentially built off of GOTO. Without GOTO at assembly level, programming wouldn't be possible.

The question is, then, is GOTO appropriate for high level programming? I believe emphatically that it is. If we could simply use a loop wherever a GOTO would be useful, the matter would be different. But GOTOs allow us to cut corners, and to divert program flow in very complex ways in very clear code. Yes, I said 'GOTO' and 'clear' in the same sentence.

This is one of the most common reasons one must embrace GOTO - escaping multiple nested loops of death. The break command will only ever leave one loop, meaning you will have to keep a flag telling the other loops to terminate. More elegant is:

while (something)

while (something)

while (something)

{

if (I_want_to_get_out)

goto Out;

}

Out:

//more code

GOTO is often criticized for not letting code be read in a linear way by anyone reading it, because it could potentially hop all around the place. Potentially hopping around the place and actually hopping around the place are different. In truth, most GOTO usages keep with linear reading of code. The above code had the GOTO label within view of the GOTO statement - very readable.

Additionally, using GOTO can lead to many optimizations in critical parts of code that a compiler might not pick up on, such as avoiding additional variables to keep track of things that a GOTO can easily avoid. Overall it is in my firm belief that we should not be too hasty in abandoning GOTO in high level programming, instead taking the route of making GOTOs more readable but essentially the same statement. C++ makes a good step towards this by allowing the same GOTO label names in multiple functions, although there is a general need to make label names for each and every GOTO that still makes the process less refined than other high level constructs at the moment.