Empirical Study On How C Devs Use Goto In Practice Says "Not Harmful"

Edsger Dijkstra famously opined in 1968 on the danger of Goto statements. New submitter Mei Nagappan writes with a mellower view, nearly 50 years later: By qualitatively and quantitatively analyzing a statistically valid random sample from almost 2 million C files and 11K+ projects, we find that developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared, thus suggesting that goto does not appear to be harmful in practice. (Here's the preprint linked from above abstract.)

Comments

I prefer the Comefrom statement

[Anonymous Coward]

It gives me so much more flexibility and power. The computed comfrom is even better.

why?

[Anonymous Coward]

Is that because they were warned by Djikstra that it would be harmful to use it haphazardly? Or is it for some other reason?

Re:why?

[firewrought]

Is that because they were warned by Djikstra that it would be harmful to use it haphazardly?

Programmers are more used to structuring their code (using functions, modules, etc.) and using best practices (minimizing globals, separation of concerns, etc.). This was not so much the case in the late 60's. That, combined with the "goto stigma", means that average developers avoid goto usage and good developers know when it's worth it.

We saw a similar backlash with the concept of operator overloading. People abused it in C++, the Java designers overreacted and prohibited it, but most languages since then recognize that "yeah, operator overloading's really nice when you're building an API for mathematical constructs" (like complex numbers, quaternions, and matrices). So it's there in C#, Python, D, Rust, Scala, but (from the little I've seen) people seldom abuse it these days.

Re:why?

[Anonymous Coward]

Really? You loose point for what is really the most sane way to handle cleanup in C? Have the instructors in those courses actually done any real work outside of academia? This is a very common pattern that I've seen in almost every large C code base that I've worked on.

static int
do_some_work (context_t context,
              int x,
              error_t **error)
{
    int rv = 0;
    database_t *db;
    data_t v;

    db = get_db (context, error);

    do some work ...

    v = compute_v (context, db, error);
    if (!v)
        goto out;

    more work ...

out:
    return rv;
}

It makes it so much cleaner and easier to read.

Re:why?

[Anonymous Coward]

If I worked for someone as rigidly blind as yourself, I'd have left years before you "fired me", "manager in your dreams".

THE ONLY RULE is that rules are meant to make you think carefully before you break them.

Rules are for the guidance of the wise and obedience by fools.

You, sir, are a fool.

Re:why?

[tepples]

How many levels of nested if blocks are you willing to tolerate solely in the name of avoiding a single use of the keyword goto?

Re: why?

[Darinbob]

What if I actually am an expert? Am I still bound by your superstitions about goto?
It's one thing to tell a student or beginner to avoid goto, but another thing to place an absolute prohibition on them.

The original goto-considered-harmful paper was written at a time when structured programming was extremely rare, spaghetti code was common, and the flowchart was a common design method. We're decades past that time though and the general programming style everywhere is to be highly structured. So the same repulsion about using goto is no longer necessary, we know enough to not use it at a whim but should be allowed to use it when it is indeed appropriate in languages which do not have the necessary structured constructs to avoid it.

What's the term for a prophylactic prediction?

[myvirtualid]

There is an implication that Dijkstra was wrong about the goto - the implication being based on how conservatively it is used.

Perhaps it is wiser to conclude that the goto is used so conservatively because Dijkstra was right and that programmers have, in general, taken his wisdom to heart and avoided the goto except for those instances where, properly documented, it is the best tool for the job.

(By prophylactic prediction I mean the sort of warning or planning that completely forestalls the danger predicted, through awareness, preparation, etc. Kind of like the Y2K non-event.)

goto fail

[Anonymous Coward]

https://www.imperialviolet.org/2014/02/22/applebug.html

Way to bury the lead

[Chess_the_cat]

Headline should read "Thanks to Dijkstra's warning, GOTO in practice not harmful."

Re:How much unsafe use has Dijkstra prevented?

[Anonymous Coward]

As someone who saw the programming practices of the 1960s and early 1970s, I can assure you that Dijkstra's warning was needed.
It caused a massive change in practices among software professionals, within a few years GOTO had almost disappeared from most new code.
I remember seeing code from a "sales engineer" in 1975 that was so full of buggy gotos that we refused to even attempt to debug it.
He learned.

longjmp()

[stox]

is far more entertaining than a mere goto.

You shoulda seen programs before Djikstra!

[mileshigh]

In the 60's and much of the 70's, most people wrote in high-level languages as if they were coding assembler. Goto's all over the place. Not that they had a choice -- for example, control flow in Fortran IV, the most-used high-level language of the time, featured IF, DO (a crude version of the modern FOR -- not do), GOTO, CALL, RETURN. No else, while, do/while, no modern-style for, case, etc. AND, get this: NO BLOCKS; the IF statement controlled only a *single* statement, so that meant you often *had* to say IF (...) GOTO xxx. Just like assembler. It was awful! There were other less-popular but more-evolved languages, but unstructured practices were very often carried over to those as well. GOTOs were just how most programmers thought.

That's the backdrop for Djikstra's condemnation of GOTO. Certainly, the then-current mass use of GOTOs was a very bad thing since it completely obscured program logic. If you read the original article, he's not so much condemning GOTO as he's arguing for structured programming.

Consider GOTO Considered Harmful as a successful wake-up call. By keeping his message black/white, i.e. GOTO is bad, he gave his message punch and made it much talked-about. People started to think in a more structured manner (though at first we thought the "structured crowd" were a bunch of weenies), and started to demand better control-flow features. Pretty soon, structured control-flow was de rigeur in any new or revised language. Fortran even got IF/END IF in Fortran 77!

People nowadays have hardened the anti-GOTO bias into gospel. At the time, the response was more nuanced, more in line with the spirit of what Djikstra was saying. For example, in 1974 even Niklaus Wirth's new PASCAL (a principled, hard-line structured language if there ever was one) included the goto statement with the warning in the User Manual and Report that "the goto statement should be reserved for unusual or uncommon situations where the natural structure of an algorithm has to be broken." If anybody was going to out-and-out outlaw goto, Wirth would have been the guy.