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

51–60 of 207 posts

Re: Goto (2007)

#51

Post by SAI_Peregrinus »

mikevm wrote: post #14
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.

Should've used setjmp/longjmp to do the same thing. Make it even harder to reason about.

Re: Goto (2007)

#52

Post by IshKebab »

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 at all like that. `goto` leads to hard to follow, bug-prone code.

> Why would an otherwise sane person write code with "rep" and without ever using "jmp"?

They wouldn't. Nobody is suggesting that you should avoid `jmp` in assembly. I think maybe you missed the point? The whole "avoid goto" thing is talking about higher level languages than assembly that provide proper flow control primitives like `if`, `for`, `switch` and so on.

Re: Goto (2007)

#54

Post by zabzonk »

ahartmetz wrote: post #47
zabzonk wrote: post #38

Earlier quoted context omitted.

Please explain a little more with an example. Certainly not in my C code, though I a huge fan of RAII in C++.

A function that allocates resources in several steps jumps, on error, to the teardown part at the end to deallocate (in reverse order of allocation) only the resources that were allocated. The others are skipped (jumped over). It's very popular in the Linux kernel.

> only the resources that were allocated

How does it know which were allocated and which were not? If you are talking about memory allocation, then you could simply deallocate all the pointers provided they were initially set to NULL. Freeing a NULL pointer is well-defined in C.

Re: Goto (2007)

#55

Post by mumblemumble »

throw_m239339 wrote: post #40
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"?

> 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"? There is no need to use GOTO when a language has functions/procedures and exceptions. Of course it makes sense in Assembly…

One thing a C-like goto has over exceptions is that you can only jump around within a single lexical scope. That restriction is a big win for readability.

Exceptions use a dynamic scope to decide where to jump to, so, in the general case, it's a lot harder to understand how they will affect program behavior by simply reading the code. That's a major reason why using exceptions for non-exceptional control flow is widely considered to be evil.

Re: Goto (2007)

#56

Post by zabzonk »

panax wrote: post #45
zabzonk wrote: post #38

Earlier quoted context omitted.

Please explain a little more with an example. Certainly not in my C code, though I a huge fan of RAII in C++.

Here is an example with RAII and goto: https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consi... Btw that is a Cert C recommendation to use goto for RAII! Take a look at the Linux kernel sometime, goto is everywhere there too https://www.kernel.org/doc/html/v4.10/process/coding-style.h...

Not many of us are kernel developers, or agree whole-heartedly with their practices.

Re: Goto (2007)

#57

Post by TheCapn »

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.

It's a rule given to those still learning the craft. Some people just don't realize that once you gain a level of expertise you should question the rules you were given and make educated decisions on whether those rules were just guard rails to help you learn or actual constraints put in for a real purpose.

When I was early on in code I abused the GOTO, once I learned it was taboo, I was forced to learn how to structure functions/statements in a way that flowed smoothly and created readability in the code that wasn't there before. Now that I understand the pitfalls, I use goto primarily in the "Bailing Out" form described int he link. To try and force the code to do what it does without the goto would likely create a bigger mess as I'd just be nesting statements beyond ever growing if-else branches designed to kick out when failure conditions occurred.

Re: Goto (2007)

#58

Post by GuB-42 »

I think we must distinguish between forward and backwards goto. And whether or not you are entering blocks.

If you are not entering blocks, forward goto is usually fine, and for me, there is no good reason to think is is worse than break, continue and return. In fact, I would more readily ban mid-function return than this kind of goto.

Backwards goto is when you get spaghetti code, there is some use for it, but it is very easy to make a mess.

Entering blocks is particularly bad because it breaks both flow and initialization, I think if there is one kind of goto that should be considered harmful, that's the one, these can even break compilers. But as always, if there is a good reason to do it, why not, but you need a lot of convincing.

Re: Goto (2007)

#59

Post by SAI_Peregrinus »

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…

> using SHA-1 as a non-secure hash,

That I actually partly disagree with. There are much, MUCH better performing (faster, less memory use, etc) hashes than SHA1 if you don't need security. If you don't need security, and you don't need performance, and you don't have anything else available in libraries, then SHA1 is fine. But that's a pretty rare situation. SHA1 might not be a sign of insecurity, but it's often a sign of poorly thought out design.

Re: Goto (2007)

#60

Post by zabzonk »

amelius wrote: post #31
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"?

Goto can, conceptually, really mess with the semantics of initialization and finalization of local variables.

Indeed, which is why C++ forbids (and the compiler checks) such jumps.
Post reply on HN