Sunday, December 02, 2012

GOTOs, considered

Extreme programming is old hat now, safe even. The world is ready for something new, something tougher, something that'll... break through. You know? . And here is what the world's been waiting for: Transgressive Programming.

The Transgressive Manifesto is quite short:

It's okay to use GOTO.
The single underlying principle is that we value willful controversy over mindless conformity.

I do have a serious point here. Even programmers who haven't read the original article (because they can't spell Dijkstra and so can't find it through Google) know that GOTOs are "considered harmful". But as Marshall and Webber point out, "the problem lies ... in the loss of knowledge and experience. If something is forbidden for long enough, it becomes difficult to resurrect the knowledge of how to use it."

How many Oracle developers even realise PL/SQL supports GOTO? It does, of course. Why wouldn't it? PL/SQL is a proper programming language.

The standard objection is that there is no role for GOTO because PL/SQL has loops, procedures, CASE, etc. But sometimes we need to explicitly transfer control. In recent times I have have across these examples:

  • a loop which raised a user-defined exception to skip to the END LOOP; point when the data was in certain ststes, thus avoiding large chunk of processing. A GOTO would have have been cleaner, because it is poor practice to represent normal business states as exceptions.
  • a huge function with more than a dozen separate RETURN statements. GOTOs directing flow to a single RETURN call would have been really helpful, because I needed to log the returned value.
  • a condition which set a counter variable to a large number so as to short-circuit a loop. Here a GOTO would simply have been more honest.
These examples are all explicit control transfers: they cause exactly the sort of random paths through the code which Dijkstra inveighed against. But the coders didn't honour the principle underlying his fatwa, they just lacked the moxie to invoke the dread statement. Instead they kludged. I'm not saying that using a GOTO would have redeemed a function with 800 LOC ; clearly there'e a lot more refactoring to be done there. But it would have been better.

Here is a situation I have come across a few times. The spec is to implement a series of searches of increasing coarseness, depending on which arguments are passed; the users want the most focused set of records available, so once a specific search gets some hits we don't need to run the more general searches.

Nested IF statements provide one way to do this:

    result_set := sieve_1(p1=>var1, p2=>var2, p3=>var4, p4=>var5);

    if result_set.count() = 0
    then
        result_set := sieve_2(p1=>var2, p2=>var3, p3=>var4);

        if result_set.count() = 0
        then
            result_set := sieve_3(p1=>var3, p2=>var5);

            if result_set.count() = 0
            then
                ....
            end if;
        end if;
    end if;      
    return result_set;     
Obviously as the number of distinct searches increases the nested indentation drives the code towards the right-hand side of the page. Here is an alternative implementation which breaks the taboo and does away with the tabs.
    result_set := sieve_1(p1=>var1, p2=>var2, p3=>var4, p4=>var5);
    if result_set.count() > 0
    then
        goto return_point;
    end if;
    
    result_set := sieve_2(p1=>var2, p2=>var3, p3=>var4);
    if result_set.count() > 0
    then
        goto return_point;
    end if;

    result_set := sieve_3(p1=>var3, p2=>var5);
    if result_set.count() > 0
    then
        goto return_point;
    end if;
    ...
    << return_point >>
    return result_set;     
I think the second version has a clearer expression of intent. Did we find any records? Yes we did, job's a good'un, let's crack on.

tl;dr
GOTO: not as evil as triggers.

Labels: , , ,

4 Comments:

Blogger Jonathan said...

Good article. I used to use your second pattern -- many GOTOs pointing to a single RETURN -- in COBOL quite often. (In COBOL it was to a single EXIT). It's very handy to have a single exit from a routine.

3 December 2012 04:13:00 GMT-8  
Blogger APC said...

I@Jonathan - I started out with COBOL. ITL Mini COBOL in fact, which was a reduced set of COBOL 66 and GOTOs were the only mechanism we had for control transfer. Perhaps that's why I'm comfortable with them.

4 December 2012 20:31:00 GMT-8  
Blogger Kevan Gelling said...

Excellent article. I've used GOTOs to improve my program structure for years.

I'm always surprised by other programmers adherence to the 'Do not use GOTOs' mantra when they are perfectly happy to use EXCEPTIONs. The difference is in name only.

6 December 2012 05:43:00 GMT-8  
Blogger Joel Garry said...

The difference between good and bad gotos is the constraint put on where they go. If they are just being used as an exit or another version of an exception, fine, I did that 30 years ago and I do it now.

But you have to maintain someone else's seriously brain-damaged spaghetti code to truly understand harm with evil intent.

I'm not so sure I understand the poor practice of representing normal business states as exceptions - from my view, there is a continuum from unpredicted states to states not well-defined; it's a natural consequence of placing strict logical definitions on fuzzy or evolving business practices. Even in the most loopy design paradigms, there comes a time when you can't go back and redefine business parameters in a timely manner.

18 December 2012 12:15:00 GMT-8  

Post a Comment

<< Home