|
No they are not.
Break is designed to allow breaking out of a construct in a predictable, limited way.
OK, in generated code, the result is still a branch, but one is much less likely to lead to abuses of control flow, particularly with later maintenance.
|
|
|
|
|
Point well taken.
The misuse of Branches (or Jumps or whatever a given syntax may use) is probably one of the factors that led to the abandonment of assembly language; my true love.
ICEs with a good 32 instruction backward trace capability will almost always provide the debug needed.
But that's a moot point these days. The "consensus" has decreed, and so I (and thousands of others) suffer.
Sad.
|
|
|
|
|
I hate being restricted by programming standards that explicitly say "you should not use gotos". What is the point of using a language that has gotos and not being allowed to use them. It is like someone giving you an ornamental chocolate and your mum telling you that you aren't allowed to eat it because it looks pretty. Why did they give it to us if we weren't meant to eat it. Why does a language have gotos if we are not allowed to use them.
When I was in airlines, the technical manager said that if anyone wanted to use gotos, he wanted a writeup of reasons. Now here was a challenge: all I had to do was reproduce the essay "structured programming using gotos" which I wrote when I was in Uni (1976), with snippets of how much simpler the code was with gotos than without. It was about 3 pages. The goto restriction was lifted for me and no one ever questioned it. The same thing happened when I was in medical. Guess they had never dealt with a real computer scientist before. Everyone else was an ex engineer, astronomer, mathematician or physicist. They just read about programming concepts: they never had to do the research or write up essays on simple, everyday things like use of do-while-false loops or indentation styles.
|
|
|
|
|
Blame has been put on the goto statement by a very famous article.
In the old days of FORTRAN, with its old fashioned control statements, including conditional, assigned and computed goto's, or in early versions of the Basic language with its goto/gosub mechanisms, you had little other option to control the flow of execution than branching to numeric labels. Writing clean code was indeed a challenge, as it was hard to make the structure of the code apparent.
Things have changed a lot thanks to structured languages so that pinches of goto's every here and there are quite acceptable, and possibly more advisable than some contortions used to avoid them at all costs.
My favorite usage is when implementing state machines, every state being represented by a jump label and the decision-making block of code following it, which includes a number of explicit branches to other states. Such coding can involve tenths of goto's, while remaining crystal clear readable.
|
|
|
|
|
I'm still using GOTOs, not in my C# / JAVA / C++ code but in my SQL Code.
It is still very usefull in SQL for error handling, MS introduced the BEGIN/END TRY/CATCH structure but it is not portable on version of SQL older than 2005 and it is absolutely not portable "as is" on another SQL Engine and most of the customers I've worked for have that mandatory requirement to be able to switch engine as they see fit (even if 90% of them will never take that step and stick to MS SQL Server).
|
|
|
|
|
Goto is a perfectly well usable statement. It's been considered a bad practice from the times people tended to write spaghetti code by using only goto for flow control in their code.
It is a tool, and if you use it right, it will help you write simple and maintainable code. But as with any tool, if you use it in a bad way, you get what you deserve.
If I have nested code, if-then, several levels deep, I prefer goto. Much cleaner. Writing a function that throws the same exception in 10 places (example elsewhere in this discussion, with the critique he should have used exceptions) is more complex than the provided sample with the gotos (which I like). Could have done it myself.
As a note; Lua 5.2 (released 2012) got the goto statement as a new enhancement to the language (so after 20 years of Lua)
Cigarettes are a lot like hamsters. Perfectly harmless, until you put it in your mouth and light it on fire.
|
|
|
|
|
I am not afraid to say I used it at least 4 or 5 times! (in the last 10 years!...)
Even once recently!
I hate the mindless peer pressure against it, use it even it's ugly if you like!
Use whatever makes your code more beautiful! ^^
Just so you know, the (mindless violent) hate against it is based on the following argument: "it's not maintainable" i.e. "it break the flow of the code which should be otherwise obvious"
That much is true, long methods with goto label hidden 300 line below are big traps. But this is true of 300 lines method without goto too!!!
So, shortly, use it if it's the shorter more expressive solution. If someone doesn't like it, suggest them to fix the code. And choose the most expressive readable code between theirs and yours after that!
Anyway, when one use goto?
Err... truthfully only one C# exemple comes to my mind (apart switch):
how to break out simple of multiple nest loop
for ()
for(..)
for(..)
{
if(condition)
goto exit_loop;
}
exit_loop:;
Just so you know, a typical C goto will be for clean up, as in
if (success1) {...}
else goto failure
If (sucess2) { ...}
goto failure
...
return;
failure:
but in C# this is more nicely expressed with try {} catch {} finally {} which doesn't need any goto
|
|
|
|
|
Oh, this is nice example for bad logic.
|
|
|
|
|
DanielSheets wrote: It can make for cleaner code if used correctly.
Post an example then, or it isn't so.
I see you did, in another sub-thread, see my response there for a cleaner equivalent.
modified 4-Mar-13 6:29am.
|
|
|
|
|
The goto is not required, you can always skip around with variable but sometime it's the best solution.
In this example the goto is a clear simple example, remove it and you introduce less readable and more complexity.
function BigFunction() {
for (int i =0; i < 100; i++) {
while(true) {
if (...) {
goto DO_SOMETHING_AT_THE_END;
}
}
}
DO_SOMETHING_AT_THE_END:
DoSomething();
}
|
|
|
|
|
I think this example is pretty much the only justfiable use these days. I'm not ashamed to say that I use it this way occassionally. I much prefer that to deep nesting and multiple function returns. Multiple function returns often introduce bugs that could be avoided by using goto.
But I'm wary of the religious wars against using goto so when I do use it I make sure I could justifty it in a code review.
|
|
|
|
|
I strongly disagree. This calls for splitting the function into two, if not more, pieces and/or rethinking the algorithm.
I've seen code like this cause way too many bugs when something is introduced in the middle of BigFunction which doesn't get cleaned up at the end.
|
|
|
|
|
You have the right to disagree, I'm saying this is a case where I see goto have it's usefulness.
Yes you can split into multiple function but sometimes there is 10+ parameters involved and creating subfunction doesn't make it clearer.
I respect your opinion and your strict mode but don't get me wrong... all languages [more or less] have the goto keyword or an equivalent.
|
|
|
|
|
It is often considered OK to call a goto from a deeply nested loop in order to terminate all loops altogether early, without the need of adding and maintaining several guard variables in the loop conditions. Of course if you can afford to place your loop in a separate function, you can also return from that, eliminating the goto but still doing the same.
|
|
|
|
|
Been writing code since '85. Never used a goto in production code and I would have serious issue[s] with anyone who did.
|
|
|
|
|
Good luck writing any assembly code without it.
|
|
|
|
|
Good luck getting me to write production assembly.
|
|
|
|
|
I wrote assembly for years and never used "goto".
|
|
|
|
|
That is why I alias goto to JMP!
|
|
|
|
|
see my example the message above your.
If goto were that bad new language like C# would not have include it. It has a purpose, but it must be use in special case. Yes it can be avoided but something it the most clean solution.
|
|
|
|
|
Yes, quite.
So you would have serious issue[s] with the people who wrote:
jpeglib
libsoap
lua runtime
mongoose
gifencod
etc. (just the examples I have at hand).
Never had much of a problem maintaining/debugging a flow control that uses a label.
Switch statements have probably caused more problems.
But then I'm just being objective.
|
|
|
|
|
There is the "goto" in C# switch. That I have used lately.
Otherwise I regard break and continue as instances of goto: break is the good guy (forwarding) where continue is the bad guy (backwarding(!)).
/ Normann
|
|
|
|
|
GOTO is a vital tool for programmers wanting to develop high performance applications.
In my primary commercial product (a GUI engine used by other programmers) I use it over a dozen times.
Even the likes of Alexander Stepanov consider it useful, so I am in good company.
|
|
|
|
|
Its been beaten into me over the years not to use GOTO's.
Programming languages differ, but most have some sort of if / then / else that makes clearer programming than goto. Loops with leave / break statements, etc.. Even Fortran has these (I used it before it did)...
I find indenting with GOTO replacements clearer to follow than hunting for GOTO's and their destination. Esp if you have huge functions.
Even DOS batch scripting has if / then statements. Few years ago I cleaned up some messy batch scripts to make them readable...
|
|
|
|
|
The only place I can think where it might still be used in modern high-level languages is if one also adheres to the ancient (and out-dated?) principle that a function should have a single exit point. Sometimes making that happen without goto makes for some clunky, hard to read code with multi-level nests of IF blocks.
My sig will confirm that I agree with you, though I haven't used goto since I abandoned QuickBasic some 15 years ago, and haven't written assembly in 20+.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|