An empirical study of goto in C code | Hacker News Reader

An empirical study of goto in C code

peerj.com

24 pointsdeclan11 comments

This study is ridiculous. Dijkstra's paper was written before C was. There's no reason to believe that he was referring to the style used commonly in C code.

Edit: I just mean the tone the study writer takes is ridiculous. It is good to know that goto is used thoughtfully.

Indeed. He was talking about using goto as the main control structure instead of e.g. functions or if/else. In C, you can't even have a goto outside of a function.

We can go stronger than that. The real point of Dijkstra's paper was to argue in favor of structured programming. C is a structured programming language. Dijkstra won so thoroughly that we've collectively forgotten what he was arguing about.

To replicate the goto that Dijkstra was complaining about in C, you would have to put the entire program in the main function, use no for loops or switch statements, and use if statements with bodies that only jump to labels and contain nothing else in their bodies. Nobody programs like that for their entire program. Dijkstra won.

(On occasion, people structure a function as a state machine rather than a stack, but generally only in special circumstances. C-style error handling is also simply using the language tools to implement exceptions, not unstructured programming.)

> if statements with bodies that only jump to labels and contain nothing else in their bodies.

For extra verisimilitude, you'd have to re-invent the 'arithmetic if' statement. Since most programmers working now have no idea what that is, I'll explain:

    IF (A-B) 10,15,45

That is an 'arithmetic if' statement; it means "If A-B < 0, goto line 10. If A-B == 0, goto line 15. If A-B > 0, goto line 45."

That's it. You can't change which number it compares the expression to. You can't change the fact it's just a conditional goto with a somewhat more involved than usual conditional. (You can work around these things, but it involves doing more by hand, which languages should ameliorate.)

That was introduced to the high-level language world in an ancient version of FORTRAN, apparently copied by some BASIC dialects which didn't know any better, and then totally ignored for decades, a trend I heartily endorse.

> Nobody programs like that for their entire program.

That's exactly how I programmed when I was learning BASIC in elementary school. :-) I still remember my friend trying in vain to explain what a FOR loop did, and I remember when it finally occurred to me why GOSUB/RETURN wasn't pointless. It really makes me appreciate structured programming!

In other words ... program it on pure assembly without macros

> We conclude that developers limit themselves to using goto appropriately in most cases, and not in an unrestricted manner like Dijkstra feared

So this is pretty much the control flow equivalent of someone complaining about memory errors in languages like C (dangling pointers/memory leaks), and then much later some academics look through some code written in a managed GC'ed language like Java or C# and decide that the original complainer really didn't have anything to worry about.

Yup, that's it.

Fun paper. I conclude that the warning worked: goto is used carefully and with restraint.

I suspect you could generalize this to many similar language construct and tool warnings/anti-patterns.

Except csh. It's always harmful.

I subscribe to the theory that the average use of goto in the sample set is not toxic because of Dijkstra's warning.

Don't forget that `Dijkstra` let you GOTO anywhere you wanted, something impossible in modern implementations.

Reply on news.ycombinator.com