goto statement
-
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;
-
You mean you are 'grown up'! Can't believe that... :laugh: 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.
-
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.
Ahh... This is one of my favourite subjects. I think we went to the total unbalance of the overpopulation of gotos of BASIC to the total unbalance of goto starvation on structured languajes. A goto is perfect for some weird situations. Imagine your fiancee calls you at work, because you've won severals milions on LOTO. May be your exit from work will be no too structured, and so must be. In others words goto deals well with some fatal error situatios, a glance at linux kernel code shows this. What? I'm getting seriuous. goto minibar.
-
Ahh... This is one of my favourite subjects. I think we went to the total unbalance of the overpopulation of gotos of BASIC to the total unbalance of goto starvation on structured languajes. A goto is perfect for some weird situations. Imagine your fiancee calls you at work, because you've won severals milions on LOTO. May be your exit from work will be no too structured, and so must be. In others words goto deals well with some fatal error situatios, a glance at linux kernel code shows this. What? I'm getting seriuous. goto minibar.
If you don't think that
GOTO
is an interesting topic of conversation, try the Duff device. http://www.lysator.liu.se/c/duffs-device.html[^]Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899). "You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
-
If you don't think that
GOTO
is an interesting topic of conversation, try the Duff device. http://www.lysator.liu.se/c/duffs-device.html[^]Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899). "You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
:thumbsup: I'd never seen that before. Awesome.
-
Ahh... This is one of my favourite subjects. I think we went to the total unbalance of the overpopulation of gotos of BASIC to the total unbalance of goto starvation on structured languajes. A goto is perfect for some weird situations. Imagine your fiancee calls you at work, because you've won severals milions on LOTO. May be your exit from work will be no too structured, and so must be. In others words goto deals well with some fatal error situatios, a glance at linux kernel code shows this. What? I'm getting seriuous. goto minibar.
altomaltes wrote:
your exit from work will be no too structured
That's an interrupt.
-
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.
It's fine when it's the only tool in the box (very old BASIC, DCL, DOS batch files, etc.), but I've never needed it in languages that support structured programming.
-
If you don't think that
GOTO
is an interesting topic of conversation, try the Duff device. http://www.lysator.liu.se/c/duffs-device.html[^]Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899). "You are to act in the light of experience as guided by intelligence" (Rex Stout, "In the Best Families", 1950).
Could this be written by C# ?
-
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 withGOTO
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.
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.
-
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 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))
{
// Do stuff here...
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))
{
// Do stuff here...
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.
-
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.
-
There is few number of bad developers, like me, thinking the
goto
is not evil. :)Veni, vidi, vici.
-
Getting past the denial stage is the first step towards a cure. :laugh:
- I would love to change the world, but they won’t give me the source code.
-
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.
The book, "Classics In Software Engineering" has Dijkstra's excellent paper, "The Case Against The Goto". There was also another paper by another author in that book stating situations where the goto is useful. A goto is worthwhile in some very limited contexts. I found a related very short paper by Dijkstra online that is titled, "A Card Against The Goto" at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html[^]. It is more of a philosophical outlook about the issue and doesn't go into the depth of the article in the book. It's also worthwhile reading the paragraphs under "Considered Harmful" at http://blogs.perl.org/users/erez_schatz/2011/07/rewriting-the-language.html[^]. That section tells about how when Dijkstra's article, "The Case Against The Goto" was submitted to the ACM magazine, the editor changed the title [to "Gotos Considered Harmful"] and created a furor! Two key sentences at the link above are: "It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist." However, it is true that, in the vast majority of cases, using a goto can and should be avoided. But it's also a mistake to revile any code that contains a goto merely because the code contains one. By the way, I also agree with another poster that multiple returns in a function are undesirable, although I can see exceptions for this too. A single return in a function makes debugging so much easier. I make a serious effort to have only a single return, however, I have broken this guideline at times, particularly when working on critical legacy code where I wanted to minimize changes to the code. Here's a construct in pseudo-code that I've used in both C and C++ programs to avoid the need for gotos for multiple error cases. (By the way, I also always put the parenthesis in a statement, even for only one-line statements, because it makes the code easier to maintain. Typically, 85% of the cost, or time, spent on code is maintenance, so typically, code should be written to make it easy to maintain, as opposed to making
-
The book, "Classics In Software Engineering" has Dijkstra's excellent paper, "The Case Against The Goto". There was also another paper by another author in that book stating situations where the goto is useful. A goto is worthwhile in some very limited contexts. I found a related very short paper by Dijkstra online that is titled, "A Card Against The Goto" at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html[^]. It is more of a philosophical outlook about the issue and doesn't go into the depth of the article in the book. It's also worthwhile reading the paragraphs under "Considered Harmful" at http://blogs.perl.org/users/erez_schatz/2011/07/rewriting-the-language.html[^]. That section tells about how when Dijkstra's article, "The Case Against The Goto" was submitted to the ACM magazine, the editor changed the title [to "Gotos Considered Harmful"] and created a furor! Two key sentences at the link above are: "It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist." However, it is true that, in the vast majority of cases, using a goto can and should be avoided. But it's also a mistake to revile any code that contains a goto merely because the code contains one. By the way, I also agree with another poster that multiple returns in a function are undesirable, although I can see exceptions for this too. A single return in a function makes debugging so much easier. I make a serious effort to have only a single return, however, I have broken this guideline at times, particularly when working on critical legacy code where I wanted to minimize changes to the code. Here's a construct in pseudo-code that I've used in both C and C++ programs to avoid the need for gotos for multiple error cases. (By the way, I also always put the parenthesis in a statement, even for only one-line statements, because it makes the code easier to maintain. Typically, 85% of the cost, or time, spent on code is maintenance, so typically, code should be written to make it easy to maintain, as opposed to making
I prefer:
// Some code here. Entering a section with lots of error checking.
// Some code goes here that sets an error condition.
if (!error)
{
// Some more code that sets an error condition.
if (!error)
{
// Even more code that sets an error condition.
if (!error)
{
// etc.
}
}
}
// The code continues here.No "do...while" required. This also has the advantage that excessive indenting reminds the programmer that they need to break the code out into method calls to simplify the layout. Once it gets past four or five indents this becomes obvious. Better would be:
// Some code here. Entering a section with lots of error checking.
// Some code goes here that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// Some more code that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// Even more code that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// etc.
}
}
}
// The code continues here.This way each error can be reported as necessary, perhaps with some cleanup or roll-back code.
- I would love to change the world, but they won’t give me the source code.
-
The book, "Classics In Software Engineering" has Dijkstra's excellent paper, "The Case Against The Goto". There was also another paper by another author in that book stating situations where the goto is useful. A goto is worthwhile in some very limited contexts. I found a related very short paper by Dijkstra online that is titled, "A Card Against The Goto" at http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html[^]. It is more of a philosophical outlook about the issue and doesn't go into the depth of the article in the book. It's also worthwhile reading the paragraphs under "Considered Harmful" at http://blogs.perl.org/users/erez_schatz/2011/07/rewriting-the-language.html[^]. That section tells about how when Dijkstra's article, "The Case Against The Goto" was submitted to the ACM magazine, the editor changed the title [to "Gotos Considered Harmful"] and created a furor! Two key sentences at the link above are: "It should cease to exist. Nothing in programming is definite. There is no single element that is either a silver bullet or the Antichrist." However, it is true that, in the vast majority of cases, using a goto can and should be avoided. But it's also a mistake to revile any code that contains a goto merely because the code contains one. By the way, I also agree with another poster that multiple returns in a function are undesirable, although I can see exceptions for this too. A single return in a function makes debugging so much easier. I make a serious effort to have only a single return, however, I have broken this guideline at times, particularly when working on critical legacy code where I wanted to minimize changes to the code. Here's a construct in pseudo-code that I've used in both C and C++ programs to avoid the need for gotos for multiple error cases. (By the way, I also always put the parenthesis in a statement, even for only one-line statements, because it makes the code easier to maintain. Typically, 85% of the cost, or time, spent on code is maintenance, so typically, code should be written to make it easy to maintain, as opposed to making
I remember that when I started learning programming in 1985 or before that the version of the language I started with was build with no loop statements, except the FOR loop. This made it relied heavily on GOTO statement in the case of conditional loops. I think for languages,if any, with such structure one HAVE to use it, with care.
-
I prefer:
// Some code here. Entering a section with lots of error checking.
// Some code goes here that sets an error condition.
if (!error)
{
// Some more code that sets an error condition.
if (!error)
{
// Even more code that sets an error condition.
if (!error)
{
// etc.
}
}
}
// The code continues here.No "do...while" required. This also has the advantage that excessive indenting reminds the programmer that they need to break the code out into method calls to simplify the layout. Once it gets past four or five indents this becomes obvious. Better would be:
// Some code here. Entering a section with lots of error checking.
// Some code goes here that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// Some more code that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// Even more code that sets an error condition.
if (error)
{
// Report error details here.
}
else
{
// etc.
}
}
}
// The code continues here.This way each error can be reported as necessary, perhaps with some cleanup or roll-back code.
- I would love to change the world, but they won’t give me the source code.
That code is you showed is fine, and I also prefer the the nested form of error checking when it is manageable. That isn't always the case. (Note the comment in my last message, there is no "silver bullet!") As I wrote in my code example, "That construct avoids the extreme indenting that can occur with a lot of nested error checks." The key words are "can" and "nesting". Deep nesting cannot always be easily avoided by breaking into functions, and when that is the case, the loop construct is useful. For the example below I used the nested form to compare 8 keys, where the values of the 8 keys form a single key to a dictionary (or a map). Each item in the map is sorted in lexicographic order. (This code snippet is taken from the article Generic Sparse Array and Sparse Matrices in C#[^]
public int CompareTo(ComparableTuple8 group) { int result = this.Item0.CompareTo(group.Item0); if (result == 0) { result = this.Item1.CompareTo(group.Item1); if (result == 0) { result = this.Item2.CompareTo(group.Item2); if (result == 0) { result = this.Item3.CompareTo(group.Item3); if (result == 0) { result = this.Item4.CompareTo(group.Item4); if (result == 0) { result = this.Item5.CompareTo(group.Item5); if (result == 0) { result = this.Item6.CompareTo(group.Item6); if (result == 0) { result = this.Item7.CompareTo(group.Item7); } } } } } } } return result; } #endregion }
That is 8 keys.
-
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))
{
// Do stuff here...
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))
{
// Do stuff here...
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.
ERROR: Symbol "workedOK" is undefined in this context
The difficult we do right away... ...the impossible takes slightly longer.
-
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.
I have never needed to use a GOTO statement in any language since BASIC. And when I wrote a recursive extension to the GOSUB function (along with a couple other snazzy enhancements) in Commodore PET's BASIC, I never needed one again either. Marc