Recently while looking over the shoulder’s of some fellow devs I was witness to something disturbing.  If you haven’t guessed by now it was a goto statement.  An intern we used to have had used gotos in a switch(case) statement since in C# switch(case) doesn’t allow fall-through.

You have to do:

int shippingOption = getShippingOption();
switch(shippingOption)       
      {         
         case 1:   
            cost += 25;
            goto case 2;                 
         case 2:            
            cost += 25;
            goto case 3;           
         case 3:            
            cost += 50;
            break;       
         default:            
            Console.WriteLine("Please select 1, 2, or 3.");            
            break;      
       }

I have to admit that this is the only situation where I feel gotos should be allowed.  The problem with the code that they were looking at looked more like:

switch (n)
    {
    case StaticVar1:
        if (statusVariable == 0)
        goto StaticVar3;
        statusVariable = 9;
        DoSomething();
        if (statusVariable == 3)
        goto StaticVar2;
    case StaticVar2:
        if (statusVariable == 0)
        goto StaticVar3;
        statusVariable = DoSomething2();
        goto StaticVar1;
    case StaticVar3:
        if (statusVariable == 0)
        break;
        statusVariable = DoSomething3();
        if (statusVariable == 2)
        goto StaticVar2;
...insert a whole bunch more...
    default:
        break;
    }

which really had more like 10 different cases.  The problem is that he wasn’t using the gotos to do fall-through.  He was using them like your classic old VB days of gotos.  

Hopefully we all know who Dijkstra is.  Dijkstra is well-known for two things in his career as a computer scientist.  The first thing, of course, is Dijkstra’s algorithm for best pathing.  If you have ever had to implement a best path algorithm Dijkstra’s is simple to do, pretty straight forward and it works.  Of course since he created it back in the 60’s others have come out that improve on his best path algorithm but still at the core of the improved algorithms are Dijkstra’s algorithm.  I mean, come on, he has an algorithm named after him, wouldn’t that be cool?  Anyways, the second thing he is known for is his article “Go To Statement Considered Harmful” in the March 1968 Communications of the ACM.

“Dijkstra observed that the quality of code was inversely proportional to the number of gotos the programmer used.” (McConnell, 2004)  

So what?  The code works.  

Well, not really.  As McConnell says above, speaking on Dijkstra’s article, the quality of the code was inversely proportional to the number of gotos.  That’s right, more bugs, harder to troubleshoot, harder to maintain.

Additionally gotos break the fundamental concept of software development that code within a method (procedure, function) flows from top to bottom.

Fine Brian, I still don’t believe you and you suck.  I mean how are we supposed to handle OnError in VB.Net?

Um, by following the preferred methods of handling exceptions as outlined in:
http://msdn.microsoft.com/en-us/library/aa289194.aspx
which is an article entitled “Life Without On Error Goto Statements”

Well, fine but goto statements allow for faster and cleaner code.

Um, no it doesn’t.

“Goto statements break the flow of code tending to thwart compiler optimization actually leading to slower executing code” (McConnell, 2004)

Now, a follow up letter to the ACM was published in March of 1987 (yeah, 20 years later) entitled “‘GOTO Considered Harmful’ Considered Harmful” by Frank Rubin, in which the he gave what he considered the seminal example for goto statements, when gotos should be used and the advantage they gave.  The letter was followed by over 50 responses, some of which supported Frank but quite a few gave samples where his goto example would be better served as a method call or some other preferred way other then a goto.

I have looked at millions upon millions of lines of code, most of which is other people’s code.  It truly is a great learning experience.  The example at the top for fall-through are the only time I’ve seen that gotos might be used.  Even in the example at the top the goto’s really aren’t needed and be worked another way.

I could spend sometime analyzing all the arguments for gotos but unfortunately I don’t have that time.  Studies show goto statements hurt code.  That’s all there is.  Want to get out of deeply nested loops?  Use status variables instead of gotos.  Want to move within a switch(case)?  Don’t.  It’s bad programming and can be done with a small bit of code duplication that will end up saving cycles in compiler optimization and code maintenance.  Sure you save a few seconds coding but in reality you’re costing yourself and/or your organization a lot more in maintenance.

If you’re used to using gotos help out your fellow man (or maintenance programmer) and spend a few more minutes working without gotos.

We all will thank you.

Every time you forward this to someone a kitten won’t get kicked.  Think of the kittens.

Brian

Refs (Additional Reading):
Code Complete (Second Edition), Microsoft Press, Steve McConnell, 2004

Life Without On Error Goto Statements, Deborah Kurata, July 11, 2003
http://msdn.microsoft.com/en-us/library/aa289194.aspx (dead link)

I’d Consider That Harmful, Too, Jeff Atwood, October 25, 2007
https://blog.codinghorror.com/id-consider-that-harmful-too/

goto (C# Reference), November 2007
http://msdn.microsoft.com/en-us/library/13940fs2.aspx

Go To Statement Considered Harmful (see also A Case against the GO TO Statement), E.W. Dijkstra
Association for Computing Machinery (ACM), Communications of the ACM, March 1968