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

11–20 of 207 posts

Re: Goto (2007)

#11

Post by zabzonk »

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.

Well, in C you very rarely need it, but in assembler (particularly the 8-bit Z80 and 6502 that I've written raft-loads of code for) you definitely do. Of course, something like a CALL is better, if you can manage it.

Re: Goto (2007)

#12

Post by scoutt »

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.

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

Re: Goto (2007)

#13

Post by Wildgoose »

I remember getting "sniffy" comments for using a GOTO in my final year project, (which was written in Pascal).

Basically, it was used to terminate the program without having to thread a return-value through very heavily nested code.

I haven't needed to use a GOTO since. But almost 35 years later, I still maintain it was the correct decision at the time: a single GOTO statement was the clearest and most efficient choice.

Re: Goto (2007)

#14

Post by mikevm »

0xTJ wrote: post #9

Blanket rules like "never use `goto`" are generally not great. A big part of the job of a software developer is knowing when to use what bits of a language. Sometimes code with `goto` is simply easier to understand. You have to be careful, but dismissing it completely is throwing out a tool.

People who give blanket rules such as never to use `goto` clearly do not understand where this idea comes from or why it should not be used. Many years ago in my undergrad I submitted a programming assignment in C which used `goto` for cleanup, as is customarily done in the Linux Kernel and other C software and I had points taken off for using `goto`. Heh.

Re: Goto (2007)

#15

Post by mysterydip »

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.

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

Re: Goto (2007)

#16

Post by mytailorisrich »

scoutt wrote: post #12
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 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".

Re: Goto (2007)

#17

Post by mikevm »

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.

Re: Goto (2007)

#18

Post by enriquto »

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.

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 control flow is based on goto.

Re: Goto (2007)

#19

Post by bigbillheck »

Structured programming has won so thoroughly and become so pervasive that it's hard nowadays to understand the context in which Dijkstra was writing.

'Don't use goto' doesn't mean 'never ever use a goto under any circumstance', it means 'consider using this thing called a "while" loop instead'.

Re: Goto (2007)

#20

Post by hyperman1 »

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 they have to convince themselves that actually it is OK.

Hence I only do these things if they are overwhelmingly good. They have not only to be worth it to be written that way, but also be worth it to do the repeated discussion that they are worth it every few months. They deserve a huge comment, containing benchmarks or proof of security or whatever. If the construction is only slightly better, I go with the slightly worse construction.

Post reply on HN