Goto, Break and Continue
category: offtopic [glöplog]
Hey guys.
Can I have your opinions on the use of goto, break and continue statements in code?
Thanks,
Molive
Can I have your opinions on the use of goto, break and continue statements in code?
Thanks,
Molive
I would be careful to equate the use of goto with the other two.
I refuse to write anything that compiles into something containing jmp instructions.
"If it looks stupid, but it works, it isn't stupid."
They all have their place. Goto might be best avoided though unless you really need it, and if you do, it still might be worth it to consider alternatives.
@gargaj: you don't have to have the same opinion on all three
They tend to be treated with a lot of hypocrisy. Usually, a pitchfork-wielding know-it-all would have a mantra like "goto bad, break continue good" in their headbone.
I don't use goto because I was conditioned not to and it's hard to come up with a good excuse to use it anyway. And while I think that break and continue are also a form of goto, I use them liberally, often because I know I wouldn't be judged for that.
However, when you look at insane things like Duff's device, you realise that it's all goto anyway. Yet somehow it's cool. Also, you don't mention return statement: when used in the function body it's goto as hell.
I don't use goto because I was conditioned not to and it's hard to come up with a good excuse to use it anyway. And while I think that break and continue are also a form of goto, I use them liberally, often because I know I wouldn't be judged for that.
However, when you look at insane things like Duff's device, you realise that it's all goto anyway. Yet somehow it's cool. Also, you don't mention return statement: when used in the function body it's goto as hell.
I disagree with that sentiment.
The reason people don't shun break/continue/return is because their use is always intrinsically paired with another control flow statement (break/continue with for/do/while, return with a function block), so even though they're technically a goto, the outer structure confines you to what sort of jump you're executing, whereas an actual goto goes across your normal program flow; it's essentially a patch cable you solder on the back of a board - if you need it, you've probably done something wrong.
The reason people don't shun break/continue/return is because their use is always intrinsically paired with another control flow statement (break/continue with for/do/while, return with a function block), so even though they're technically a goto, the outer structure confines you to what sort of jump you're executing, whereas an actual goto goes across your normal program flow; it's essentially a patch cable you solder on the back of a board - if you need it, you've probably done something wrong.
Avoid goto!
But break, continue and also return are very commonly used in high-level-languages like c# or java, and they aren´t anything to avoid really, they are just needed instruments to be played in certain cases. Take a switch-block (as in a state-machine for example), you need those breaks to not fallthrough into other cases! But its all very controlled behaviour unlike a goto somewhere in your code branching to somewhere completely else in your code!
I use all of them even in C(++), just because they are best practice in many cases!
But break, continue and also return are very commonly used in high-level-languages like c# or java, and they aren´t anything to avoid really, they are just needed instruments to be played in certain cases. Take a switch-block (as in a state-machine for example), you need those breaks to not fallthrough into other cases! But its all very controlled behaviour unlike a goto somewhere in your code branching to somewhere completely else in your code!
I use all of them even in C(++), just because they are best practice in many cases!
In any high level programming language, the instruction goto is just a hack. In any machine code language, every instruction is a hack. :]
"Know when to use them, and know when not to use them"... but this tells you nothing, of course.
The stigma around goto (and even the other two, as there are people raising their pitchforks against those as well) is pretty stupid, because it makes you stop thinking and start believing in their dogma.
(Also some context: Dijkstra's paper was written when there was no if/for/while stuff at all. Using a few gotos in your code isn't really the subject of his criticism, and it will probably not hurt using some. To me, breaking out of an n-fold nested loop using a goto is more clear than setting n-1 loop state variables, then breaking.)
I don't really care about either, as long as it works (but that's a fairly low bar). The largest problem arises when you need to work with other people, but complex code will still be complex even when it's "clean". But for simple democode only you work on, the advice is "who cares lol". Just make a demo.
The stigma around goto (and even the other two, as there are people raising their pitchforks against those as well) is pretty stupid, because it makes you stop thinking and start believing in their dogma.
(Also some context: Dijkstra's paper was written when there was no if/for/while stuff at all. Using a few gotos in your code isn't really the subject of his criticism, and it will probably not hurt using some. To me, breaking out of an n-fold nested loop using a goto is more clear than setting n-1 loop state variables, then breaking.)
I don't really care about either, as long as it works (but that's a fairly low bar). The largest problem arises when you need to work with other people, but complex code will still be complex even when it's "clean". But for simple democode only you work on, the advice is "who cares lol". Just make a demo.
One very practical problem with goto can be object lifetimes (constructors/destructors being called, or not?), you don't have those with break/continue. Use goto when you absolutely know what you are doing and you know it's better than the alternatives. Otherwise, there is most likely a better solution.
Quote:
Dijkstra's paper was written when there was no if/for/while stuff at all
FLOW-MATIC is from the mid 1950s and has IF statements, I think that predates Dijkstra's paper a bit.
Quote:
One very practical problem with goto can be object lifetimes (constructors/destructors being called, or not?), you don't have those with break/continue. Use goto when you absolutely know what you are doing and you know it's better than the alternatives. Otherwise, there is most likely a better solution.
As far as I understand the C++ standard (and most compilers) forbid this, i.e. at least if you go-to into the scope of a local variable that is not POD bypassing its declaration/constructor, in which case an error should be generated. Goto in C++ seems to respect RAII as far as destructors go though.
longjmp ftw
well I strongly approve break
noby: My VS 2015 generates a warning in that case, not an error. Which is kind of mind-boggling when you think about it...
Preacher: yeah, based on some googling VS isn't standards compliant in this case: https://stackoverflow.com/a/2406807
The only valid reason to use goto in a higher level language (in my opinion) is in state machines:
C# example:
C# example:
Code:
void ChangeState(EState newState)
{
this.state = newState;
switch(state)
{
//...
case EState.Bar:
{
//...
}
break;
case EState.Foo:
{
//...
this.state = EState.Bar;
goto case EState.Bar;
}
break;
}
}
which language is the op referring to anyhow?
Breaking out of a nested loop is also a valid use case for goto. And error handling when there are multiple cases of failure.
FWIW, I find jumping around inside a switch-case like that really confusing to follow. I think I'd rather recursively call ChangeState again in that case just to be on the clear side.
FWIW, I find jumping around inside a switch-case like that really confusing to follow. I think I'd rather recursively call ChangeState again in that case just to be on the clear side.
FunGas: This is in the context of C#.
I used goto once, to make a complex recursive code works, please never do that.
(to compute ambient occlusion on a blocks system)
not sure about continue though, most of the time I use it because Im lazy to make a new function, its bad..