Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goto (2007)

beej.us

Post reply on HN
Print view View original

21–30 of 207 posts

Re: Goto (2007)

#21

Post by mytailorisrich »

mysterydip wrote: post #15
mytailorisrich wrote: post #10

Earlier quoted context omitted.

It's not arbitrary. The goal is to improve quality by making the code better structured and easier to follow. For instance, MISRA C rule 15.1 that states that goto should not be used explains: " Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand ". Indeed, in practice that's often the case.

Isn't the key word in that statement "unconstrained"? Goto is a tool like any other that can be abused.

That's why there is this rule to constrain it!

It is pragmatic, practical, and clear to have a rule not to use it. This forces people to make the effort to structure their code. Now, if it so happens one day that the result is indeed worse than using goto then a conscious decision can be made to make a specific exception. Otherwise, this is the sort of thing that will creep up and cause unless discussions.

Re: Goto (2007)

#22

Post by samhw »

enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

> Or those novels that do not ever use the letter "e".

As a note on this, I think the novel you're talking about is Georges Perec's 'La Disparition'. Supposedly the lack of an 'e' is symbolic of the loss of his family in the Holocaust. Anyway, I always thought one of the greatest feats of the English language was the guy who translated the novel to English, also omitting the letter 'e'. Absolutely mindblowing talent.

Re: Goto (2007)

#23

Post by panax »

When you are forced to follow stupid rules like having only one exit point in a function then goto can be used a lot in place of that, but what are we supposed to do if you are not allowed to both use goto or have multiple returns in a function (in C) ?

Re: Goto (2007)

#24

Post by lelanthran »

mytailorisrich wrote: post #10
enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

It's not arbitrary. The goal is to improve quality by making the code better structured and easier to follow. For instance, MISRA C rule 15.1 that states that goto should not be used explains: " Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand ". Indeed, in practice that's often the case.

> For instance, MISRA C rule 15.1 that states that goto should not be used explains: "Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand"

Sure, but constrained uses are fine, right? So why blanket-ban it?

Re: Goto (2007)

#25

Post by einpoklum »

mikevm wrote: post #17
me_me_me wrote: post #7

The only acceptable use-case for goto I came across was for error handling and cleanup. If there are multiple points of code failure that all require same cleanup procedure then one section at the bottom is acceptable and can actually keep the code cleaner. Anything else looks like bad design that ends up producing hard to follow code.

Yes, this is pretty much how it is being used in C code. The other acceptable use-case is breaking out of nested loops. There's also `setjmp()`/`longjmp()` but that's even more rarely used.

longjmp() is the C-language version of going-to labels in other functions.

Its basic "use" is not having to unwind the stack; but moreover, it lets you avoid cleanup and resource de-allocation. Usually it doesn't make sense to do that (you get memory leaks), but if, say, your memory allocations happen in some kind of arena - you can just leave it in any junk state and then proceed to clear it altogether after your setjmp() instruction.

Re: Goto (2007)

#26

Post by simion314 »

hyperman1 wrote: post #20

There are a few situations like this, where a bad practice is in a specific case good enough: Using goto to bail out multiple levels, using SHA-1 as a non-secure hash, ... The problem is these things waste social bandwith: Someone reading your code for maintenance or code review will first declare the code bad (GOTO is ugly! SHA-1 is insecure!), then you have to signal to them that it's actually OK in this case, then…

You can link them to the manual, good languages documentation explain clear and when examples when is better to use GOTO. If there is an asshole in the team the official documentation would calm them down after they will be probably shocked that their cool language implemented this "evil" feature.

Re: Goto (2007)

#27

Post by panax »

enriquto wrote: post #18
mytailorisrich wrote: post #10

Earlier quoted context omitted.

It's not arbitrary. The goal is to improve quality by making the code better structured and easier to follow. For instance, MISRA C rule 15.1 that states that goto should not be used explains: " Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand ". Indeed, in practice that's often the case.

I agree with you; and I keep a printed copy of the MISRA C document on my nightstand for serene reading before sleep (together with the JPL C rules). Yet this point 15.1 does not forbid at all to use goto, just to use goto in an unconstrained way. Thus it is more a warning than a rule. In the same spirit, you can also enjoy Knuth's "structured programming with goto statements" for a clean programming style whose cont…

And yet we were recently forced to change a lot of code which did use goto in a constrained way(for error handling only), because someone decided to make 15.1 required instead of advisory and take 15.1 too literally (they also made 15.5 no multiple returns required as well) and some of the results were worse than if someone had used goto in an unconstrained way.

Re: Goto (2007)

#28

Post by mumblemumble »

enriquto wrote: post #4

Coming from assembly language, I always found the anti-goto sentiment rather cute. A beautiful restriction, but ultimately arbitrary. Like writing poetry. Or those novels that do not ever use the letter "e". Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

> A beautiful restriction, but ultimately arbitrary. Like writing poetry.

This assessment cuts pretty close to the gist of (my reading of) Dijkstra's famous paper that kicked off the anti-goto sentiment, once you take some time to digest the entirety of the paper and consider the context in which it was being written.

I'd also like to throw out there, though, that the "go to" statement he describes is a "go to" statement that functions like the one in programming languages from before 1968. Which is a goto statement that, I'm guessing, very few of us have ever used. Early versions of BASIC - the "20 GOTO 10" variety - are maybe the most well-known example nowadays. If you've spent much time with a Commodore 64 or a 1st-generation IBM PC, you're probably familiar.

He wasn't criticizing C's goto. Not just because C hadn't been invented yet. His most lucid, damning criticisms of goto in higher-level languages can't really be leveled against C's goto statement, because C's goto simply doesn't exhibit the features he's criticizing.

Re: Goto (2007)

#29

Post by tyingq »

Perl has goto, but it also supports labels you can apply to loops, and call for redo, next and last. Where "next" is like "continue" and "last" is like "break".

Re: Goto (2007)

#30

Post by scoutt »

mytailorisrich wrote: post #16
scoutt wrote: post #12

Earlier quoted context omitted.

I kind-of agree with parent, but I would define it "subjective" instead of "arbitrary".

Well, as per my previous comment it's not subjective, either. It's a "best practice" in the correct sense of the term. I.e. in most cases it is both not needed and clearer, more structured code may be written without using it. Of course, as for anything, it is useful in a very few cases, emphasis on "very few".

> improve quality by making the code better structured and easier to follow

"clearer" and "structured" doesn't matter from a compiler point of view. Hence the only ones that can judge "clearer" or "structured" is us, human beings, and that's why I think it's subjective.

"goto" is seen as "incorrect" only because of mere subjective reasons: "it's not clear", "it's not structured", "I read in a forum that it's bad", etc.

The keyword exists, it works as intended, and it's safe to use when used correctly, as all the things around programming languages.

To me, Rust code is a mess and I cannot get used to it. It's not "clearer" even if it's proven to be bug free and all that.

Post reply on HN