Hacker News Reader

Comment by dale_glass | Hacker News Reader

The "Goto Statement Considered Harmful" paper kinda overshot its mark, IMO.

It made perfect sense back when people were writing BASIC full of "GOTO 110" and "GOTO 520" that resulted in a tangled mess. Unfortunately it caught on so well that it resulted in people being really obsessive about it, and rejecting every single instance of it in C code, even in places where it makes perfect sense and makes the code cleaner.

View on HN

Goto in C (and worse, setjmp) is almost always a workaround for a deficiency in C. Examples:

The "goto cleanup" idiom to do deferred work (I don't like defer or finally in languages which have them, but at least these are language constructs which say what we wanted, the goto cleanup idiom only achieves that in some very easy cases, in more complicated cases your actual intent will be unclear)

The "iterator escape" idiom to get out of some larger iterative operation we're doing because we just realised we want to give up / found the overall answer. This is lack of imagination in the language's / library's / eco-system's control flow semantics and is one reason I really like Rust's core::ops::ControlFlow.

What is your proposed alternative for `defer`? (suppose hidden "RAII" control flow doesn't count)

It doesn't. Or, rather, RAII flow is strictly, explicitly better.

Kotlin‘s return/break@<implicit or explicit loop label> handles the iterator escape idiom quite elegantly.

> This is lack of imagination

Code shouldn't require imagination. Sometimes the simple and readable solution is just better.

How about the "threaded interpreter" idiom?

I agree. Also if people really believe goto is bad, lets not forget the 'hidden gotos' like early return oder state machines.

I’ve worked with people who stick to “only one return statement per function”. Super annoying.

The no else statement shit drives me up the wall. Sometimes code is more readable when it says what you mean. Sometimes I want to branch, other times I want to return early. There is a difference in what I mean and code should reflect that even if the opcode is the same.

I'm one of those and rather unsure of its value. The original reason is the modelling of the program as a reducible graph (if I'm not getting confused with other stuff).

I occasionally have a couple of returns in one func but only for very, very simple and short funcs where it's clearer.

I dunno. Perhaps the problem is we're missing some higher level procedural construct - any ideas?

I think it depends on the situation, but a single return statement per method does make it a bit easier to read a method and understand flow control.

At the top of the function, "if [special input] return [special output]" is a great way of handling edge cases

Really exit can be pretty useful though.

Doing if(condition) return at the start, before it gets going often reduces indentation and how many branches you need to see at once.

But I can agree sneaky returns can bite you sometimes

We've adopted single entry / single exit except for short functions (< 10-15 lines), where all the returns are clearly visible at once. It seemed to placate both sides, and it allows you to write that simple 'findFoo' function that returns 'foo' as soon as it finds it.

The 'hidden gotos', especially like an early return, for me have stricter guarantees and limitations than a goto used in the same way. Goto and labels can do too much for me to like them, i prefer more specific things with clearer boundaries and intent.

What are these guarantees? One is that they are easier to miss when reading the code.

Sorry, I don't fully understand what you mean by that. Are "early returns" easier to miss when reading code (easier to miss than goto statements achieving the same effect)? If that was your intended meaning (sorry I am missing some sleep today) I don't share that view, I think both statements are equally obvious in that regard.

Examples I was thinking about:

* an early return can only go back to the call-site

* all returns in a function or method return to the same place

* an early return terminates the context it is in

* an early return does not create an entry point for nearly arbitrary other code points as labels for gotos do

It has been, literally, many decades since I last found a place where C++ code would benefit from use of a goto statement.

Those few places where they appear in (what would have been) defensible C code are better served by reliance on destructors. I.e., it is much better to start compiling the C code with a C++ compiler, and then clean it up.

I've come across a couple of (admittedly niche) cases where C++ code benefits from a goto:

- In some very performance sensitive cases. It helps you skip a bunch of extra checks or variables.

- When you need to convert recursion to iteration, but want to keep the code structure mostly intact so you don't mess up the source control history.

Agree, minimizing diffs (even indentation!) is a necessary evil.

Nowadays I will use lambdas that return early in preference to goto. Not from fastidiousness so much as to avoid confusing the optimizer.

Poster child for reprehensible use of goto is procmail.

Destructor are not allowed to throw exceptions, so you cam only do stuff that guarantees not to throw.

These BASIC goto statements are pretty tame. Some basic interpreters did not require the line number in the statement to be constant. You could do things like a switch:

  switch n{case 1: case 2: case 3:}

would become e.g.

  goto n*100+1000

with lines 1100,1200,1300 handling the cases.

And then there was the hidden advanced troubleshooting console:

  input N: GOTO N

This is how you do a SWITCH statement in Microsoft’s command language (for .bat files) I think.

It does come in handy in some scenarios:

    choice /c abc
    goto choice%errorlevel%

    :choice1
    :choice2
    :choice3

Or, for command-line parameters:

    set ops=a b c
    set op=%1
    for %%p in (%ops%) do if "%op%"=="%%p" goto %op%
    goto usage

Structured programming makes perfect sense in lieu of the rather silly rejection in this article that holds no more water than ‘Fortran has goto and no structured programming and that is what I’m used to’.

goto makes sense in C for cleanup of local resources. Passing a bunch of pointers to pointers to another function for cleanup makes code far less readable (jumping around in a source file instead of just reading code linearly and freeing local resources in the scope in which they were allocated). Basically, forcing structured programming over using goto is the anti-lambda — requiring a lot of jumping around in the SOURCE file (not necessarily the binary) instead of linearly scanning through the code.

Dijkstra was wrong with his “goto” paper. It’s fine to admit that. He was right about most other things.

Sure, there are uses. But they are not in this article. The article argues that without goto, an if statement can only conditionally execute one statement.

> The paper doesn't explain to us what would be the use of the "if" statement without a "goto" to redirect the flow of execution: Should all our postconditions consist of a single statement[…]?

Yes, the article is a joke.

His name is Robert Paulson.

Reply on news.ycombinator.com