goto [modified]
-
I don't use it because I understood why it was regarded as bad, and I've never been in a situation where goto would have made my code better. The closest I would get is to regard goto as another way to handle code that is at least as well handled by try/catch. Not sure what you mean by 'making private methods for the sake of avoiding goto', if you have code that needs to be pointed to only sometimes, refactoring it to a new method just makes sense.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
Not sure what you mean by 'making private methods for the sake of avoiding goto', if you have code that needs to be pointed to only sometimes, refactoring it to a new method just makes sense.
Eh, now that you ask, I can't think of any examples. Maybe you have a point. So what makes it bad if you know not to use it in a bad way?
-
Ah, but one could argue that exceptions should only be used for errors[^].
Do not use exceptions for normal flow of control. Except for system failures, there should generally be a way to write code that avoids exceptions being thrown.
Error Raising and Handling Guidelines[^]
Do not use exceptions for normal or expected errors, or for normal flow of control.
I am talking about those situations where goto is used for error handling and clean up. In fact that is the most common use I have seen in c++ code aka MFC and ATL.
void FunctionWithGoTo()
{
if (!(OpenFile()) GoTo Cleanup;if (!FileFormatIsValid()) GoTo CleanUp;
if (!RecordExists()) GoTo CleanUp;
....
CleanUp://Do some clean up work like closing the file
}You can rewrite it
void FunctionWithGoTo()
{
try
{
OpenFile();
ValidateFileFormat();
ValidateRecordExists();
.... other stuff
}
catch(//appropriate exceptions)
{}
finally
{
///Cleanup
}}
If you use RAII you can simplify the code further. So I guess it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
I was taught that its OK to create a method, how ever small it may be, if even for only 1 line of code (although that would be completely pointless wouldn't it?) as it makes the code easier to update and maintain at a later date. I was also taught, and have heard, and imagined, that goto can create a really big mess, it it would be wise to avoid it. As it is, i've not come across the need for a goto.
My current favourite word is: PIE! Good ol' pie, it's been a while.
-
I was taught that its OK to create a method, how ever small it may be, if even for only 1 line of code (although that would be completely pointless wouldn't it?) as it makes the code easier to update and maintain at a later date. I was also taught, and have heard, and imagined, that goto can create a really big mess, it it would be wise to avoid it. As it is, i've not come across the need for a goto.
My current favourite word is: PIE! Good ol' pie, it's been a while.
Yep, goto can make a real mess, and it's never necessary to use. But it can make things more intuitive to understand for someone reading the code, provided you use it right. Classic example:
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
goto found;
}Console.WriteLine("5 not found");
return;found:
Console.WriteLine("5 at " + i);
return;Compared to:
bool found;
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
{
found = true;
break;
}
}if(found)
Console.WriteLine("5 at " + i);
else
Console.WriteLine("5 not found");return;
Something about that extra bool and if/else really bugs me. As for extra methods, I personally don't like making more private methods unless that code gets called more than once. Of course, if it is, I don't hesitate to make a new method because I hate writing the same code twice more than I hate writing twice as much code.
-
I am talking about those situations where goto is used for error handling and clean up. In fact that is the most common use I have seen in c++ code aka MFC and ATL.
void FunctionWithGoTo()
{
if (!(OpenFile()) GoTo Cleanup;if (!FileFormatIsValid()) GoTo CleanUp;
if (!RecordExists()) GoTo CleanUp;
....
CleanUp://Do some clean up work like closing the file
}You can rewrite it
void FunctionWithGoTo()
{
try
{
OpenFile();
ValidateFileFormat();
ValidateRecordExists();
.... other stuff
}
catch(//appropriate exceptions)
{}
finally
{
///Cleanup
}}
If you use RAII you can simplify the code further. So I guess it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
What about Win32API calls that return HRESULTS instead of throwing exceptions? As for an example of how I'd use goto, here's one[^]. Simple stuff like that that just makes code easier to read.
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
In the 500K+ lines of code I have written in the last 10.5 years I have less than 10 gotos. Mostly because I don't find myself in situations where they would improve things.
John
-
reinux wrote:
So, is it only because you've been taught not to use goto that you don't use it?
No I never had any reason to use it. If you keep function small and use exception handling you don't need to use goto.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
Rama Krishna Vavilala wrote:
I never had any reason to use it [goto]. If you keep function small and use exception handling you don't need to use goto.
But are exceptions any better that goto's? Joel Spolsky might say no. In fact, in one of his articles, Joel writes that:
...I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: 1. They are invisible in the source code... there is no way to see which exceptions might be thrown and from where.[...] 2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function.
Now, I won't go out there as far as he did and say that exceptions are worse that goto's. But I don't see exceptions as being significantly better. A goto is to your control flow as a pointer is to your data. Both can be significantly misused. However, it is appropriate to use them at times. Joel's second problem with exceptions is too many possible exit points. I believe there should be a single exit from a function. I would rather use
goto exit_;
// many lines snipped
exit_:
return foo;than have multiple returns in a function. It's too difficult when you have multiple returns and you need to modify the behavior to add a bit of logic at the end. At least, that's my opinion.
-
Yep, goto can make a real mess, and it's never necessary to use. But it can make things more intuitive to understand for someone reading the code, provided you use it right. Classic example:
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
goto found;
}Console.WriteLine("5 not found");
return;found:
Console.WriteLine("5 at " + i);
return;Compared to:
bool found;
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
{
found = true;
break;
}
}if(found)
Console.WriteLine("5 at " + i);
else
Console.WriteLine("5 not found");return;
Something about that extra bool and if/else really bugs me. As for extra methods, I personally don't like making more private methods unless that code gets called more than once. Of course, if it is, I don't hesitate to make a new method because I hate writing the same code twice more than I hate writing twice as much code.
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
{
Cosole.WriteLine("5 at " + i);
return;
}
}
Cosole.WriteLine("5 not found");I am not a fan of 1 exit per function rule anymore as it has become outdated as functions IMHO should not be more than 25 lines. I refactor any functions which go more than 25 lines. or better yet
int i = array.Find(5);
if (i == -1)
Console.WriteLine("Not found");
else
Console.WriteLine("Found");Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
-
What about Win32API calls that return HRESULTS instead of throwing exceptions? As for an example of how I'd use goto, here's one[^]. Simple stuff like that that just makes code easier to read.
Win32 APIs are meant for C.
Hope is the negation of reality - Raistlin Majere
-
Yep, goto can make a real mess, and it's never necessary to use. But it can make things more intuitive to understand for someone reading the code, provided you use it right. Classic example:
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
goto found;
}Console.WriteLine("5 not found");
return;found:
Console.WriteLine("5 at " + i);
return;Compared to:
bool found;
int i;
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
{
found = true;
break;
}
}if(found)
Console.WriteLine("5 at " + i);
else
Console.WriteLine("5 not found");return;
Something about that extra bool and if/else really bugs me. As for extra methods, I personally don't like making more private methods unless that code gets called more than once. Of course, if it is, I don't hesitate to make a new method because I hate writing the same code twice more than I hate writing twice as much code.
reinux wrote:
Something about that extra bool and if/else really bugs me.
Me too. I think your example doesn't make much difference, one way or another. But if the loops are nested, you have to have break out of multiple levels.
-
I don't use it because I understood why it was regarded as bad, and I've never been in a situation where goto would have made my code better. The closest I would get is to regard goto as another way to handle code that is at least as well handled by try/catch. Not sure what you mean by 'making private methods for the sake of avoiding goto', if you have code that needs to be pointed to only sometimes, refactoring it to a new method just makes sense.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
Christian Graus wrote:
The closest I would get is to regard goto as another way to handle code that is at least as well handled by try/catch.
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dllxacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach." -
Rama Krishna Vavilala wrote:
I never had any reason to use it [goto]. If you keep function small and use exception handling you don't need to use goto.
But are exceptions any better that goto's? Joel Spolsky might say no. In fact, in one of his articles, Joel writes that:
...I consider exceptions to be no better than "goto's", considered harmful since the 1960s, in that they create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: 1. They are invisible in the source code... there is no way to see which exceptions might be thrown and from where.[...] 2. They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function.
Now, I won't go out there as far as he did and say that exceptions are worse that goto's. But I don't see exceptions as being significantly better. A goto is to your control flow as a pointer is to your data. Both can be significantly misused. However, it is appropriate to use them at times. Joel's second problem with exceptions is too many possible exit points. I believe there should be a single exit from a function. I would rather use
goto exit_;
// many lines snipped
exit_:
return foo;than have multiple returns in a function. It's too difficult when you have multiple returns and you need to modify the behavior to add a bit of logic at the end. At least, that's my opinion.
Tony Wesley wrote:
It's too difficult when you have multiple returns
This was true during times of Fortran, C, and Assembly when global data aND jumps. With languages such as Java and C# shorter functions make this a little conservative. I still follow the (1 exit) rule while writing C++ code but no longer follow it for writing C# as I don't exceed more than 25 lines of code in a function. Either way the aim is to write easy to understand code rather than follow the rules because it comes from Joel Spolsky or Kent beck or Martin Fowler.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
reinux wrote:
Is goto really that bad?
I don't think so. I started off in high school writing spaghetti basic with GOTOs all over the place. I didn't know any better and I'm not such many did at the time. Certainly Edsger Dijkstra did, with his 1968 letter Go To Statement Considered Harmful but no one back at Warren High School in 1971 had that notion. Along the way, I learned to write Structure Programming while taking Algol. I recall discovering that I could use GOTO in Algol and used it in a program. Dr. David E. Boddy wrote on my program in large red letters "No! NO! NO!!!". And he was right. I used it when it was unnecessary, mostly as a way out of a bad design. But there are times to use it. I recently posted a snippet of my own code with goto's over in Coding Horrors (this code wasn't the coding horror :laugh: although some may disagree)
if (keyword (TokenSubtype::Group)) { if (!group\_label (groupName)) { errorMessage = myName + ": Missing GROUP label\\n" + errorMessage; errorCode = DL\_ERROR; goto exit\_; } if (!separator (TokenSubtype::Colon)) { errorMessage = myName + ": Missing colon following GROUP label"; errorCode = DL\_ERROR; goto exit\_; }// etc...
A goto is to your control flow as a pointer is to your data. Use carefully and with discipline. And remember if you use one: even if you're right, it's like using a split infinitive; some people are going to think you're wrong.
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
For languages without exception handling (c) the goto is pretty handy for error handling. Just a cheap try / catch. You might even find a setjmp longjmp call useful on occasion for deeply nested errors.
-
Tony Wesley wrote:
It's too difficult when you have multiple returns
This was true during times of Fortran, C, and Assembly when global data aND jumps. With languages such as Java and C# shorter functions make this a little conservative. I still follow the (1 exit) rule while writing C++ code but no longer follow it for writing C# as I don't exceed more than 25 lines of code in a function. Either way the aim is to write easy to understand code rather than follow the rules because it comes from Joel Spolsky or Kent beck or Martin Fowler.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
Rama Krishna Vavilala wrote:
This was true during times of Fortran, C, and Assembly
It's still that time I think. There are more than a few people using these languages. :)
-
for(i = 0; i < array.Length; i++)
{
if(array[i] == 5)
{
Cosole.WriteLine("5 at " + i);
return;
}
}
Cosole.WriteLine("5 not found");I am not a fan of 1 exit per function rule anymore as it has become outdated as functions IMHO should not be more than 25 lines. I refactor any functions which go more than 25 lines. or better yet
int i = array.Find(5);
if (i == -1)
Console.WriteLine("Not found");
else
Console.WriteLine("Found");Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
I'm not too gung-ho about the one exit rule either, but I don't like making more methods when they only get called once. You end up having to change the arguments and parameters in two locations of code every time you decide that you want to use another local. I also don't like putting processing code in the middle of search code because it gets hard to follow execution flow (I like being able to read code in a general top-to-bottom order), and because I don't want to refractor just to fix that, for the reason I mention above.
-
Tony Wesley wrote:
It's too difficult when you have multiple returns
This was true during times of Fortran, C, and Assembly when global data aND jumps. With languages such as Java and C# shorter functions make this a little conservative. I still follow the (1 exit) rule while writing C++ code but no longer follow it for writing C# as I don't exceed more than 25 lines of code in a function. Either way the aim is to write easy to understand code rather than follow the rules because it comes from Joel Spolsky or Kent beck or Martin Fowler.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
Rama Krishna Vavilala wrote:
Either way the aim is to write easy to understand code rather than follow the rules because it comes from Joel Spolsky or Kent beck or Martin Fowler.
I'm in complete agreement with you!
-
I am talking about those situations where goto is used for error handling and clean up. In fact that is the most common use I have seen in c++ code aka MFC and ATL.
void FunctionWithGoTo()
{
if (!(OpenFile()) GoTo Cleanup;if (!FileFormatIsValid()) GoTo CleanUp;
if (!RecordExists()) GoTo CleanUp;
....
CleanUp://Do some clean up work like closing the file
}You can rewrite it
void FunctionWithGoTo()
{
try
{
OpenFile();
ValidateFileFormat();
ValidateRecordExists();
.... other stuff
}
catch(//appropriate exceptions)
{}
finally
{
///Cleanup
}}
If you use RAII you can simplify the code further. So I guess it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
In your examples, I prefer the version with the gotos. I can't tell which of OpenFile() or ValidateFileFormat() or ValidateRecordExists() might throw an exception.
-
Win32 APIs are meant for C.
Hope is the negation of reality - Raistlin Majere
They're still often the only option even from C++ or VB or any other language. Or C# for that matter, though luckily P/Invoke wraps those return values in exceptions.
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
I've only used goto once, it was to add a resume function. It struck me as simpler to impliment then to re factor the function into several smaller functions.