|
Why many hate this statement and do not advise using it! I used it when I started programming with BASIC and GWBASIC. It is also found in the C#. Troubles are based on the programmer who is misusing it.
|
|
|
|
|
Because in nearly every case I have seen of it's use in C# or C++ it has been unnecessary, and only served to both confuse the code and show that the person who used it did not understand what he was doing.
goto is not evil - but it is a "rule breaker" in that it violates all the principles of good code design and so using it should only be done with care. The problem is that it it taught on courses by lazy tutors as an easy way to get them started and then gets abused later because the students consider it "Normal" and don't learn to structure code well in the first place as a result.
If you had grown up with GOTO as pretty much the only form of flow control (as I did) you would probably understand how easy it is to create impenetrable code with it, and why it should be discouraged until the coder is experienced enough to know when it is appropriate. About five years of "real" coding should be enough. But by then, he is probably experienced enough to know that there are probably better ways to achieve the same result...
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
Very well put!
The only goto-like statement I use is a break statement.
However even at the beginning of coding in .Net I was uncomfortable using it, shaping my logic so that I did not need to use it.
At university, back in 1988, I was taught never to use a goto statement - one very rare case necessitating its use in COBOL being the exception.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
*shudder*
First language I was taught, that. Then FORTRAN to follow, which was a breath of (what seemed like structured at the time) fresh air in comparison! 
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
That's the usual reasoning and perfectly ok in most cases.
What if I need to squeeze out a better performance? Readability and maintainability now are secondary. I have done this often enough in the past and still do it today.
Writing software is not a religion and mindlessly reciting and enforcing rules does not help at all. The rules may have good reasons, but you must always understand their goals. Break them if your goals happen to be different.
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
If you know what you are doing, then you have enough experience to know when it is appropriate to use.
I completely agree with you: it's a useful tool. But like all tools, you have to know how and when to use it. Performance tuning (as you know well) needs more than just "quick code" - it needs a careful look at the whole of what is occurring and frequently a change of algorithm as well as hand-tuning of the code. And if you know what you are doing enough to do that, you understand the effects of your changes. Even Dijkstra said that it has it's place, but that use must be tempered with knowledge of the effects.
Obligatory XKCD reference[^]
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
OriginalGriff wrote: it needs a careful look at the whole of what is occurring and frequently a change of algorithm as well as hand-tuning of the code
I've done some minor bits of optimization on occasion. I've never needed goto as part of any hand-tuning. Algorithm improvements and refactoring are generally the way to go for me.
Software Zen: delete this;
|
|
|
|
|
I second that. I've done lots of performance tuning, but it never required goto. At most, goto may improve the performance of the programmer who puts it into the code - but in the long run that "performance gain" will be lost in maintenance cost mmany times over!
|
|
|
|
|
Another big consideration is use of goto's will frequently severely hamper of the ability of your compiler to optimise code - without the application knowledge, it can rarely make safe assumptions in their presence and it messes up the SSA (Static Single Assignment) style optimisations by complicating the control flow graph.
So while you may be able to think of it at as optimisation, it may prevent the compiler doing so.
It's also not high on the list of things they feel they should concentrate on, so I wouldn't count on big improvements soon.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
What? SSA transform is performed on a CFG, and it absolutely does not matter if there are irreducible sub-graphs in the flow. Not to mention a trivial fact that irreducible CFG can always be transformed into a reducible one by subgraph cloning.
|
|
|
|
|
Yes, but injudicious use of low-level constructs such as goto will add complexity to the CFG.
I know every loop, if statement etc. is implemented using branches - but they are there explicitly to avoid needing to use those lower level constructs.
Is like the argument that assembler is more efficient. Except it usually isn't in the presence of modern architectural considerations such as caching and instruction pipelines. Modern compilers can target these architectures better, and higher-level constructs similarly give the compiler hints about the intent of code that are not available with the lower-level cases.
I will acknowledge there are places where it is useful, but I'd go with the advice that it should be avoided in 99.99% of cases, and even then only if you're fully aware of the repercussions.
In my experience, almost all of the uses of goto's can be replaced by higher-level constructs. There are exceptions, like the OCAML usage, but that's a fairly unusual case to be working on code like that. Many parser generators also generate code using goto's - that one is less arguable as there are frequently better alternatives.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
OriginalGriff wrote: If you know what you are doing, then you have enough experience to know when it
is appropriate to use.
Yeah, but how do you know when you have enough experience to know when it's appropriate to use? 
And then there's my sig...
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
You mean you are 'grown up'! Can't believe that...
But as for the rest I agree with you - don't break rules just for breaking them...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
Good grief no!
I'm just old.
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
After using FORTRAN for far too long (up to Fortran-77) with it's use of GOTO and, even more obfuscating, computed gotos, I started using C. However, I was self-taught and was therefore never was taught by anybody that there was a GOTO in the language! I used C for several years, then C++ and now I am firmly in the C# camp. I personally have never used GOTO in any of that code and was shocked one day to find a GOTO residing in someone else's code I had to fix. It was a revelation as big as finding out that one is allowed to use guns during a penalty kick-off. I didn't even know the syntax existed!
The whole point of my argument is that I never felt the need for a GOTO at any time, ever - so I didn't miss it. I didn't make artificial constructs to get around using GOTO; I didn't deliberately re-write my code to avoid using one; it just came about naturally that I didn't ever need one.
Having said that, I am sure that GOTO may be useful in some real-time code somewhere for performance reasons. My real bug-bear is with multiple RETURNs. I do actually go out of my way to avoid them and re-write them out of existence wherever I find them. I have not yet found any instance where multiple RETURNs from a method has been necessary. I miss allowing the drop through of CASE statements in a switch that has been removed in C#, forcing me to put BREAK at the end of each part and leading me to repeat code unnecessarily now and then so I am not always in favour of compiler/syntax restrictions in a language but I wish multiple RETURNs had been proscribed in the same way.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I disagree to an extent with you about multiple returns: I'd rather see a method with validations at the top, each with it's own error report and a return than some "faffing about" code to avoid it.
I just think it makes the code look cleaner.
The only instant messaging I do involves my middle finger.
English doesn't borrow from other languages.
English follows other languages down dark alleys, knocks them over and goes through their pockets for loose grammar.
|
|
|
|
|
I always structure things to do validation at the top a bit like:
private bool SomeMethod(string someStingArg, int anIntArg)
{
bool workedOK = false;
if (IsValidForThisFunction(somString) && IsAlsoValid(anIntArg))
{
workedOK = true;
}
return workedOK;
}
...or, if individual validations are necessary...
private bool SomeMethod(string someStingArg, int anIntArg)
{
bool workedOK = false;
if (IsValidForThisFunction(somString))
{
if (IsAlsoValid(anIntArg))
{
workedOK = true;
}
}
return workedOK;
}
That way I still have only one exit - and I have all the validations at the top.
Obviously there are try...catch blocks involved but I wanted to put a simple layout.
- I would love to change the world, but they won’t give me the source code.
modified 10-Nov-13 18:52pm.
|
|
|
|
|
ERROR: Symbol "workedOK" is undefined in this context
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
|
I think that multiple return advice is not longer necessary in modern C++ - simply use RAII style techniques, and you are guaranteed correct cleanup at exit.
(Still shouldn't be overrused though)
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
OK, from a relative novice, here's the way I see it, and pardon me, but I come from a Qbasic/VB background.
As for multiple returns, if you have 10 conditions, lets say in a "Select case" statement, I see it OK to use multiple returns... if you have returns scattered, then I can see a problem.
I find the following a neat way of doing this... I'm usually not much for the ":", but again I find that on something simple like this, putting the condition and the return value on the same line improves readability
Select case i
case 1 : return false
case 2 : return true
case 3 : return false
end select
|
|
|
|
|
This serves as a single return as all gathered in one block
|
|
|
|
|
"Clever" use of GOTO can create macramé like code that is impossible to debug.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
Herbie Mountjoy wrote: "Clever" use of GOTO...
Not only difficult to debug, it makes it difficult to alter. I ran into code that had an if goto, code, if not goto, unlabeled code. I didn't dare change it by removing the code that would never get executed. I didn't know why the code was there or what it was supposed to do or if I missed something "clever" done.
|
|
|
|
|
OriginalGriff wrote: it violates all the principles of good code design
Actually "good" code design is an evolving thing. When I started coding, spaghetti code was normal and "good" I much prefer today's standard of "good" and look forward to new definitions of good. Just read an article about how we should eliminate IF statements. Interesting, but you can see how the "IF" was encapsulated in the routine executed. But that is part of the new "good", encapsulate and re-use existing logic.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
