goto [modified]
-
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?
My vote is YES, the Goto is okay for use if needed. Well, that is the issue though, "if needed". Back in the day, I used them often in C and C++ when I need to rip through some code and did not want endless indentation or possibly duplicating of code. Notice the keyword here is "ripping through" code. That would be when I was in a hurry and did not want to mess around with other solutions. Often the use of "goto" is simply a quick fix for either code that needs to be refactored or possibly handled differently. If you are in a hurry and need a quick fix, they can come in handy as long as you watch the saftey issues such as bypassing variable assignments. While one of my top 10 beefs with Java back in the day was the lack of a goto, I now find that I usually do not use them. It has been several years since I used a goto in any of my code. Not that I do not get in a hurry, but I find more of the work being handled by .NET/C# and much less code I need to write, so methods block size has dropped. I just do not see much of use for them anymore. I am just glad it is there in case I would ever need it.
Rocky <>< Blog Post: Updating VS 2008 B2 Websites to RTM Tech Blog Post: Cheap Biofuels and Synthetics coming soon?
-
Holy hell I just realised C# may have goto, I'm a VB person myself and assumed that goto was inflicted on us as a legacy from basic. I've been coding for a long time and I can't remember when I last used a goto - or wanted to! Let the bloody thing quietly die a death of methods that have a better alternative.
Quote from Great Outdoors: its a confident traveller who farts in India
It's a lot safer in C#. This will cause a compile-time error for using an undefined local:
goto bla;
int x = 5;
bla:
Console.WriteLine(x); -
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 just noticed something cool in C#: This'll cause a compile-time error for using an uninitialized local:
if(3 == 3)
goto bla;
int x = 5;
bla:
Console.WriteLine(x);But this'll compile just fine, albeit with an "unreachable code detected" warning:
if(3 == 4)
goto bla;
int x = 5;
bla:
Console.WriteLine(x); -
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?
One of the points consistently missed in the
goto/exceptions argument is that not only do exceptions transfer control, they also automatically clean up stack values along the way. I believe exceptions provide a better-structured method for critical error handling. Usinggoto, the code that detects the error has to select the proper endpoint for handling the critical error. In other words, the code has togotothe proper place to handle it and to ensure that all required cleanup is performed along the way. With an exception, code that needs to clean up in the event of a critical error specifies that it needs to do so (via atry/catchblock), and code that does not can ignore it. Since I started using C++, and exception support was made more robust (about VC6), I've not usedgoto.
Software Zen:
delete this; -
One of the points consistently missed in the
goto/exceptions argument is that not only do exceptions transfer control, they also automatically clean up stack values along the way. I believe exceptions provide a better-structured method for critical error handling. Usinggoto, the code that detects the error has to select the proper endpoint for handling the critical error. In other words, the code has togotothe proper place to handle it and to ensure that all required cleanup is performed along the way. With an exception, code that needs to clean up in the event of a critical error specifies that it needs to do so (via atry/catchblock), and code that does not can ignore it. Since I started using C++, and exception support was made more robust (about VC6), I've not usedgoto.
Software Zen:
delete this;Oh, of course. I don't think many people nowadays use goto over exceptions for error handling given the option is available. We were mostly talking about other scenarios.
-
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:
There are undeniably occasions in which goto enables the most readable code.
But there are one hell of a lot more where it doesn't...that's why the advise is don't use goto (unless you absolutely have to)
-
Oh, of course. I don't think many people nowadays use goto over exceptions for error handling given the option is available. We were mostly talking about other scenarios.
I can't think of any other scenario in which
gotowould be preferred over a more structured and scoped transfer of control. There might be cases where it is more concise, but I don't think that's sufficient justification compared to its potential for misuse.
Software Zen:
delete this; -
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?
To paraphrase an answer from a similar discussion: I don't use goto, but reserve the right to use it if I ever find a need for it. In more practical terms: the two good uses of goto I am aware of are: - breaking from a nested loop - ceirtan cases of machine-generated code.
-
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:
But are exceptions any better that goto's? Joel Spolsky might say no.
Exceptions are better than gotos if you know how to use them which the vast majority of developers don't. Joel is at least aware of the fact that he does not know how to use them - there are people who write about them in books and still don't get them.[^]
-
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?
-
Yep, but Rama's point was that "it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo." What I meant is that since Win32 API was written for C, if you want to use them you'll have to do it the C way, and perhaps mix it with C++ exceptions, such as:
HANDLE h = FindFirstFile(_T("AVeryImportantFile.txt"), &WIN32_FIND_DATA());
if (h == INVALID_HANDLE_VALUE)
throw CException(_T("A very important file is missing."));
Hope is the negation of reality - Raistlin Majere
An interesting solution to that problem is to create a function object to handle Win32 API calls. Then you can simply pass the function pointer to the object, the parameters, and the expected result code(s) and it can automatically do error handling, throwing exceptions, etc.. It's a bit of advance template code, but once you have it done and debugged, it's a great helper.
-- Where are we going? And why am I in this handbasket?
-
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?
no. Let me rephrase that. NO! Wait, i'm not sure i'm quite clear enough *OH MY @#$@#$ GOD #$@$@# NO!!!!!!!" Yes, it's easy to delude oneself into believing that one little goto won't hurt things, and will actually make the code cleaner and easier to use. That might even be true. TODAY. But what about 3 years from now after 50 different people of different programming levels have modified the code? Then you end up with nasty code. NEVER, EVER, EVER shake a goto. Let sleeping control flow constructs lie. Goto's breed more goto's, and they're more prolific than rabbits. If this is your own personal code, and nobody else will ever touch it... do whatever the hell you want, but in a business situation, never ever ever do anything that someone with less skill or wisdom than you might misconstrue. -- modified at 13:50 Saturday 24th November, 2007 On the other hand, this is kind of funny http://damienkatz.net/2006/05/signs_youre_a_c.html[^]
-- Where are we going? And why am I in this handbasket?
-
no. Let me rephrase that. NO! Wait, i'm not sure i'm quite clear enough *OH MY @#$@#$ GOD #$@$@# NO!!!!!!!" Yes, it's easy to delude oneself into believing that one little goto won't hurt things, and will actually make the code cleaner and easier to use. That might even be true. TODAY. But what about 3 years from now after 50 different people of different programming levels have modified the code? Then you end up with nasty code. NEVER, EVER, EVER shake a goto. Let sleeping control flow constructs lie. Goto's breed more goto's, and they're more prolific than rabbits. If this is your own personal code, and nobody else will ever touch it... do whatever the hell you want, but in a business situation, never ever ever do anything that someone with less skill or wisdom than you might misconstrue. -- modified at 13:50 Saturday 24th November, 2007 On the other hand, this is kind of funny http://damienkatz.net/2006/05/signs_youre_a_c.html[^]
-- Where are we going? And why am I in this handbasket?
Erik Funkenbusch wrote:
but in a business situation, never ever ever do anything that someone with less skill or wisdom than you might misconstrue.
so we're left with everyone doing Hello World apps then. Kewl.
-
Erik Funkenbusch wrote:
but in a business situation, never ever ever do anything that someone with less skill or wisdom than you might misconstrue.
so we're left with everyone doing Hello World apps then. Kewl.
No. I said misconstrued, not "never do anything someone with less skill or wisdom might not understand". Although I have worked at places that outlawed the use of STL because most of the developers didn't understand it, and thus wouldn't b able to maintain it. What I meant was that if you do something that, if used correctly is ok, but if used incorrectly (which is done more often than the other) it's bad, you shouldn't do it.
-- Where are we going? And why am I in this handbasket?
-
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 not needed to use goto since assembler/BASIC days, and a lot of code has flowed under the compiler since then. I honestly can't see the need for it in 99.9999999% of situations - unless you already write longwinded spaghetti in the first place (that's the only time I've encountered it in my commercial career, but fortunately for him the guy who wrote it had left by then or else he'd have had an earful from me).
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
reinux wrote:
There are undeniably occasions in which goto enables the most readable code.
But there are one hell of a lot more where it doesn't...that's why the advise is don't use goto (unless you absolutely have to)
Sure, but if you were well acquainted enough with your language that you can discern the ones that do and ones that don't, would you let anyone complain to you for using it?
-
I've not needed to use goto since assembler/BASIC days, and a lot of code has flowed under the compiler since then. I honestly can't see the need for it in 99.9999999% of situations - unless you already write longwinded spaghetti in the first place (that's the only time I've encountered it in my commercial career, but fortunately for him the guy who wrote it had left by then or else he'd have had an earful from me).
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Again it's not the need that I'm talking about; it's the appropriateness.
-
I can't think of any other scenario in which
gotowould be preferred over a more structured and scoped transfer of control. There might be cases where it is more concise, but I don't think that's sufficient justification compared to its potential for misuse.
Software Zen:
delete this;Even in skilled and experienced hands, in a language with sufficient safety netting, like C#?
-
Even in skilled and experienced hands, in a language with sufficient safety netting, like C#?
Yes. My view is that "skilled and experienced hands" don't use it because the other methods of flow control are better. My opinion isn't based upon a particular language, either. Relying on language features to save your ass is just asking for trouble. Too many programmers "play with the net down", which results in poorly-performing, resource-hogging, clumsy, buggy applications.
Software Zen:
delete this; -
Yes. My view is that "skilled and experienced hands" don't use it because the other methods of flow control are better. My opinion isn't based upon a particular language, either. Relying on language features to save your ass is just asking for trouble. Too many programmers "play with the net down", which results in poorly-performing, resource-hogging, clumsy, buggy applications.
Software Zen:
delete this;I could likewise argue that not choosing and using the tools available to you just puts you behind. C# offers safer goto just as it does foreach, yield return (which not everyone agrees is necessary), nullable types, even safer switches, and a whole slew of other language specific features. Why would anyone not use them just because they don't want to rely on a single languages's features? I mean, I could understand if you were trying to teach someone programming, you might not give them all the zero-pedagogical-value high-productivity shortcuts; and again, I wouldn't teach anyone to use goto, but in the real world, I'd raise a brow at anyone who avoids foreaches and properties. Also, it would be a long shot to say that no skilled programmers use goto, or that all programmers who use goto are unskilled.