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?
Anything used incorrectly is bad. I think the argument about goto is that it simply gives developers an easy-out rather than making them think up better constructs. As with anything there are good and bad ways to use it. Goto just seems to have way more bad ways than good ways... ...and this is coming from a die-hard VBer :)
-
reinux wrote:
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
No. Well, yeah, probably - i mean, why bother to demonize a keyword, even if it is generally misused by people who don't know what they're doing. But i'd say it's use is discouraged and rightly so. Look, goto is primitive, a very simple building-block. Unconditional transfer. Right? But the thing is, you always want conditional transfer. Think about it - you'll always use some sort of conditional to control whether or not the goto is ever reached. This is old stuff, bordering on the
je | _ne stuff |_ jmpassembler pattern or similar. It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves. The other unconditionals have very strict limits on them -break,continue,return... all transfer control, but in very specific ways. You see a return, you know you're done with the current method. You see a break, you know you're leaving the current loop (or switch...), etc. You read them and, provided you're keeping your methods and loops fairly short, can know immediately what's going to happen.gotois more of a wildcard... you can't read it without wondering what sort of odd thing is happening such that more limited control structures couldn't be used in place. I mean, heck - you can simulate subroutines withlongjmp()too, but why would you want to? ;) And yeah, it can make things more readable sometimes. Usually when things are next-to-unreadable already, and your only other hope of avoiding complete disaster is to re-write the whole mess. Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.reinux wrote:
That means several things though: -I have to scroll up and down to jump between methods
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway. If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
reinux wrote:
-I have to choose the locals that I want to use
Well... duh. How is this relevant? Do you normally work off of a big fa
Shog9 wrote:
It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves.
Yeah, but structured languages aren't exempt from leaky abstraction[^] of code flow. It's been decades since C and we still haven't come up with a good be all end all solution for breaking out of nested switches or loops. We're also still using Win32API a lot, which means we don't always have the luxury of using exception handling. Obviously I'm thankful that I don't have to use goto all the time, but that doesn't mean I'll never want to use it.
Shog9 wrote:
Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.
Never would do that. Which is why I said that if I were a teacher, I wouldn't encourage students to use it, but if someone did use it well, I'd applaud them.
Shog9 wrote:
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway.
Exactly, which is why I like to keep that at a minimum. Just because it happens doesn't mean I don't care if it happens more often.
Shog9 wrote:
If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
That's what indentation is for. Heck, I often add scope brackets just to indicate logical blocks of code. I can remember code as mental symbols that mean exactly what they do, rather than having to come up with English names that might potentially have slightly different nuances from what I'm doing. I write my code in a way that you can infer the purpose and execution flow from the shape of the code. Everything executes in a general top-to-bottom order (unless the same code happens twice or more, in which case I'll refractor), and the indentations indicate sub-routines. Which is why I don't like having processing code in the middle of search code like 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?
Yes, the goto is really that bad. I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming. (When doing assembly programming, I use the equivalent, but you really have no choice. However, even there, if I'm jmp'ing more than a page of code, I'd take a very close look at my algorithm.) Personally, I would fail any student using a goto (I won't hire anyone who uses them more than extremely sparingly.) Later, if this person encounters a situation where a goto appears to be the best solution, it will make them think long and hard and examine their code carefully before making a deliberate decision. And they'd better document why. (BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
You are missing the point. I was trying to point out that reading a method is simpler when it is written so that it calls out to other methods for any logic unrelated to it. The method then can be read like pseudocode, with the internals hidden inside other methods.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
That's what indentation is for. Heck, I often add scope brackets just to indicate logical blocks of code. I can remember code as mental symbols that mean exactly what they do, rather than having to come up with English names that might potentially have slightly different nuances from what I'm doing. I write my code in a way that you can infer the purpose and execution flow from the shape of the code. Everything executes in a general top-to-bottom order (unless the same code happens twice or more, in which case I'll refractor), and the indentations indicate sub-routines. Which is why I don't like having processing code in the middle of search code like this[^]. Makes it a lot easier to remember code too, because you get a one-to-one association between the visual shape of your code and its function.
I suppose refractoring a lot gives you the pseudocode-ish-ness advantage, but it's a pain when you're debugging, and once you forget what all those esoteric function names mean, you're going to end up having to peek inside anyway. So in a sense both ways of thinking have their advantages at different stages of development. The question would then be, which is simpler in the big picture? And honestly, I don't know, but you could argue for both.
-
Yes, the goto is really that bad. I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming. (When doing assembly programming, I use the equivalent, but you really have no choice. However, even there, if I'm jmp'ing more than a page of code, I'd take a very close look at my algorithm.) Personally, I would fail any student using a goto (I won't hire anyone who uses them more than extremely sparingly.) Later, if this person encounters a situation where a goto appears to be the best solution, it will make them think long and hard and examine their code carefully before making a deliberate decision. And they'd better document why. (BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I've found that once you tolerate any use of goto, some developers will abuse it severely.
That might be a good point as an employer. What if you're the one using goto, and you trust yourself with it?
Joe Woodbury wrote:
Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms.
Yeah, all these things can happen if you misuse it, but unreadable code and poor algorithms happen for a lot of reasons. What I'm suggesting is that, perhaps, the lack of goto can also result in such.
Joe Woodbury wrote:
(BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Yeah, I'd say. If their code is "chock full" of gotos, there's obviously a problem. Also I don't remember if C/C++ lets you goto out of a function (I never used it back then), but if it does, and people do that, well, there's your memory leak potential. I wouldn't goto over more than a few lines of code myself either.
-
Shog9 wrote:
It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves.
Yeah, but structured languages aren't exempt from leaky abstraction[^] of code flow. It's been decades since C and we still haven't come up with a good be all end all solution for breaking out of nested switches or loops. We're also still using Win32API a lot, which means we don't always have the luxury of using exception handling. Obviously I'm thankful that I don't have to use goto all the time, but that doesn't mean I'll never want to use it.
Shog9 wrote:
Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.
Never would do that. Which is why I said that if I were a teacher, I wouldn't encourage students to use it, but if someone did use it well, I'd applaud them.
Shog9 wrote:
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway.
Exactly, which is why I like to keep that at a minimum. Just because it happens doesn't mean I don't care if it happens more often.
Shog9 wrote:
If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
That's what indentation is for. Heck, I often add scope brackets just to indicate logical blocks of code. I can remember code as mental symbols that mean exactly what they do, rather than having to come up with English names that might potentially have slightly different nuances from what I'm doing. I write my code in a way that you can infer the purpose and execution flow from the shape of the code. Everything executes in a general top-to-bottom order (unless the same code happens twice or more, in which case I'll refractor), and the indentations indicate sub-routines. Which is why I don't like having processing code in the middle of search code like this[
reinux wrote:
We're also still using Win32API a lot, which means we don't always have the luxury of using exception handling.
Right, but that's generally pretty low-level stuff. Wrap it with something that makes sense for your program and be done with it.
reinux wrote:
Obviously I'm thankful that I don't have to use goto all the time, but that doesn't mean I'll never want to use it.
Of course. I'm not saying "anyone who ever uses
gotois a bad person". But it's probably a good red flag, a reason to step back and think about whether or not what you're doing really makes good sense. BTW - someone earlier mentioned RAII as a good technique for avoiding the error-handling use of goto - if you wrap your low-level API calls in RAII-friendly classes, you can toss in return code /GetLastError()-to-exception mapping as well, and just be done with it. We have trivial little wrappers floating around for most non-trivial Win32 APIs; read MSDN, write a few tests to verify that the docs are correct, and then wrap it up so it can't be misused accidentally.reinux wrote:
That's what indentation is for.
I hate seeing indentation deeper than maybe three levels. Personal preference then. :-O
reinux wrote:
Makes it a lot easier to remember code too, because you get a one-to-one association between the visual shape of your code and its function.
Absolutely true. Unfortunately, it doesn't scale. When you have to scroll through 200 lines of code to see the entire "shape", it's much harder to recognize and factor out duplicate code. Then you fix a bug in one place and the shapes no longer match up, or worse, they do but the code doesn't - and you end up with new maintainers pulling the wrong chunk of code and propagating the bug rather than the fix.
reinux wrote:
Say for instance I have a local XmlDocument that I'm going to be using throughout the entire method. I have to keep this in mind when I refractor bits and pieces of the method.
Well, to me that's another argument in favor of just breaking it up into routines that each do just one, self-contained operation on the document. Now you're passing the document in as an argument to each, but it means something different to each routine. Best yet, when you're r
-
reinux wrote:
We're also still using Win32API a lot, which means we don't always have the luxury of using exception handling.
Right, but that's generally pretty low-level stuff. Wrap it with something that makes sense for your program and be done with it.
reinux wrote:
Obviously I'm thankful that I don't have to use goto all the time, but that doesn't mean I'll never want to use it.
Of course. I'm not saying "anyone who ever uses
gotois a bad person". But it's probably a good red flag, a reason to step back and think about whether or not what you're doing really makes good sense. BTW - someone earlier mentioned RAII as a good technique for avoiding the error-handling use of goto - if you wrap your low-level API calls in RAII-friendly classes, you can toss in return code /GetLastError()-to-exception mapping as well, and just be done with it. We have trivial little wrappers floating around for most non-trivial Win32 APIs; read MSDN, write a few tests to verify that the docs are correct, and then wrap it up so it can't be misused accidentally.reinux wrote:
That's what indentation is for.
I hate seeing indentation deeper than maybe three levels. Personal preference then. :-O
reinux wrote:
Makes it a lot easier to remember code too, because you get a one-to-one association between the visual shape of your code and its function.
Absolutely true. Unfortunately, it doesn't scale. When you have to scroll through 200 lines of code to see the entire "shape", it's much harder to recognize and factor out duplicate code. Then you fix a bug in one place and the shapes no longer match up, or worse, they do but the code doesn't - and you end up with new maintainers pulling the wrong chunk of code and propagating the bug rather than the fix.
reinux wrote:
Say for instance I have a local XmlDocument that I'm going to be using throughout the entire method. I have to keep this in mind when I refractor bits and pieces of the method.
Well, to me that's another argument in favor of just breaking it up into routines that each do just one, self-contained operation on the document. Now you're passing the document in as an argument to each, but it means something different to each routine. Best yet, when you're r
Shog9 wrote:
Right, but that's generally pretty low-level stuff.
If that were true, most WinForms apps would be portable to Mono. Alas, the majority aren't. It's so severe in fact that .NET has earned its notorious reputation of lacking portability even despite a full open-source reimplementation.
Shog9 wrote:
We have trivial little wrappers floating around for most non-trivial Win32 APIs; read MSDN, write a few tests to verify that the docs are correct, and then wrap it up so it can't be misused accidentally.
That's not a bad idea. But it doesn't have too much to do with whether or not you hate gotos; it's just how you'd avoid using a goto. Which, again, do you really need to?
Shog9 wrote:
Absolutely true. Unfortunately, it doesn't scale. When you have to scroll through 200 lines of code to see the entire "shape", it's much harder to recognize and factor out duplicate code. Then you fix a bug in one place and the shapes no longer match up, or worse, they do but the code doesn't - and you end up with new maintainers pulling the wrong chunk of code and propagating the bug rather than the fix.
Again, I usually comment code if its function is non-trivial. Which means rather than giving a piece of code a "name", I give it a full-sentence description. Though I agree, at around 200 lines, I'd start thinking about pulling pieces out. Just not as early as the 25 lines that someone earlier suggested.
Shog9 wrote:
Well, to me that's another argument in favor of just breaking it up into routines that each do just one, self-contained operation on the document. Now you're passing the document in as an argument to each, but it means something different to each routine.
I'm not sure how in this case refractoring is an advantage.
Shog9 wrote:
Best yet, when you're reading the routines that don't use the document, you don't have it hanging around as a possible point of confusion.
That's a good point.
Shog9 wrote:
if i can't summarize it in a short sentence (method name), then i probably need to re-think how i've written the code in the first place.
It wouldn't be so much the grammar of the method name that I'd worry about forgetting (in PowerShell for insta
-
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.
The Undefeated wrote:
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?)
It wouldn't be pointless if that method was called in several places.
Kind regards, Pawel Krakowiak Miraculum Software[^]
-
Yes, the goto is really that bad. I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming. (When doing assembly programming, I use the equivalent, but you really have no choice. However, even there, if I'm jmp'ing more than a page of code, I'd take a very close look at my algorithm.) Personally, I would fail any student using a goto (I won't hire anyone who uses them more than extremely sparingly.) Later, if this person encounters a situation where a goto appears to be the best solution, it will make them think long and hard and examine their code carefully before making a deliberate decision. And they'd better document why. (BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming.[...]
We have different experiences. I've seen very few goto's as a professional programmer ... wait, except for those FORTRAN days. Actually, that's going to tie into the point I'm about to make. Different languages have different program control mechanisms. I used to program in a language called Clarion. One of the constructs I likes in that language was the ability to write
loop 1 times. No index variable. I would wrap it around a series of if/then/else if andbreakto exit early. In C/C++, I accomplish the same with thiswhile (true) // loop 1 time, exit at bottom { if (set (ifrFragment)) { result = true; ifrTerm = ifrFragment; break; } if (errorCode) break; if (keyword (TokenSubtype::Not) && term (ifrFragment)) { result = true; ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment; break; } if (errorCode) break; // more lines snipped break; }Robert Surtees writes We used to do it to piss off the "never use goto" zealots years ago when forbidden to use 'goto xit' for handling error conditions. And he's right. I could have done the same like this, with one few level of indentation:
if (set (ifrFragment)) { result = true; ifrTerm = ifrFragment; goto exit\_; } if (errorCode) goto exit\_; if (keyword (TokenSubtype::Not) && term (ifrFragment)) { result = true; ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment; goto exit\_; } if (errorCode) goto exit\_;// more lines snipped
exit_:So in the first example, I'm doing goto's -- without using them explicitly. Anyway, to get to my point: since different language have different control
-
Shog9 wrote:
Right, but that's generally pretty low-level stuff.
If that were true, most WinForms apps would be portable to Mono. Alas, the majority aren't. It's so severe in fact that .NET has earned its notorious reputation of lacking portability even despite a full open-source reimplementation.
Shog9 wrote:
We have trivial little wrappers floating around for most non-trivial Win32 APIs; read MSDN, write a few tests to verify that the docs are correct, and then wrap it up so it can't be misused accidentally.
That's not a bad idea. But it doesn't have too much to do with whether or not you hate gotos; it's just how you'd avoid using a goto. Which, again, do you really need to?
Shog9 wrote:
Absolutely true. Unfortunately, it doesn't scale. When you have to scroll through 200 lines of code to see the entire "shape", it's much harder to recognize and factor out duplicate code. Then you fix a bug in one place and the shapes no longer match up, or worse, they do but the code doesn't - and you end up with new maintainers pulling the wrong chunk of code and propagating the bug rather than the fix.
Again, I usually comment code if its function is non-trivial. Which means rather than giving a piece of code a "name", I give it a full-sentence description. Though I agree, at around 200 lines, I'd start thinking about pulling pieces out. Just not as early as the 25 lines that someone earlier suggested.
Shog9 wrote:
Well, to me that's another argument in favor of just breaking it up into routines that each do just one, self-contained operation on the document. Now you're passing the document in as an argument to each, but it means something different to each routine.
I'm not sure how in this case refractoring is an advantage.
Shog9 wrote:
Best yet, when you're reading the routines that don't use the document, you don't have it hanging around as a possible point of confusion.
That's a good point.
Shog9 wrote:
if i can't summarize it in a short sentence (method name), then i probably need to re-think how i've written the code in the first place.
It wouldn't be so much the grammar of the method name that I'd worry about forgetting (in PowerShell for insta
reinux wrote:
But it doesn't have too much to do with whether or not you hate gotos; it's just how you'd avoid using a goto.
If i'd solved the problem (of releasing resources on failure) using goto, the code would still have worked, yes. But now i'm letting the archaic design of the Win32 API pollute the rest of my code - something i do not wish to see at all. So really, what's the point? Perhaps i can save a small amount of time up-front by using
goto, but at the cost of harder-to-read, error-prone code. It's not just how - it's also a good part of why.reinux wrote:
Generally speaking, you could use a knife maliciously in a myriad of ways, but you can use one benevolently only maybe to cut veggies and open envelopes.
But you probably wouldn't use a letter-opener to slice veggies. In fact, i don't even keep mine in my kitchen. Sure, i could probably use it in a pinch, but i'd rather just avoid that scenario altogether. ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
reinux wrote:
But it doesn't have too much to do with whether or not you hate gotos; it's just how you'd avoid using a goto.
If i'd solved the problem (of releasing resources on failure) using goto, the code would still have worked, yes. But now i'm letting the archaic design of the Win32 API pollute the rest of my code - something i do not wish to see at all. So really, what's the point? Perhaps i can save a small amount of time up-front by using
goto, but at the cost of harder-to-read, error-prone code. It's not just how - it's also a good part of why.reinux wrote:
Generally speaking, you could use a knife maliciously in a myriad of ways, but you can use one benevolently only maybe to cut veggies and open envelopes.
But you probably wouldn't use a letter-opener to slice veggies. In fact, i don't even keep mine in my kitchen. Sure, i could probably use it in a pinch, but i'd rather just avoid that scenario altogether. ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
Shog9 wrote:
If i'd solved the problem (of releasing resources on failure) using goto, the code would still have worked, yes. But now i'm letting the archaic design of the Win32 API pollute the rest of my code - something i do not wish to see at all. So really, what's the point? Perhaps i can save a small amount of time up-front by using goto, but at the cost of harder-to-read, error-prone code. It's not just how - it's also a good part of why.
Well, if you want to write a full-blown wrapper around some Win32 functionality, that's a whole 'nother story.
Shog9 wrote:
But you probably wouldn't use a letter-opener to slice veggies. In fact, i don't even keep mine in my kitchen. Sure, i could probably use it in a pinch, but i'd rather just avoid that scenario altogether.
I meant to compare a knife with a goto, but okay. Anyway, my point is that in agreement with what Ray said, there's a lot of bad ways to use it. But there are probably good ways too.
-
Joe Woodbury wrote:
I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming.[...]
We have different experiences. I've seen very few goto's as a professional programmer ... wait, except for those FORTRAN days. Actually, that's going to tie into the point I'm about to make. Different languages have different program control mechanisms. I used to program in a language called Clarion. One of the constructs I likes in that language was the ability to write
loop 1 times. No index variable. I would wrap it around a series of if/then/else if andbreakto exit early. In C/C++, I accomplish the same with thiswhile (true) // loop 1 time, exit at bottom { if (set (ifrFragment)) { result = true; ifrTerm = ifrFragment; break; } if (errorCode) break; if (keyword (TokenSubtype::Not) && term (ifrFragment)) { result = true; ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment; break; } if (errorCode) break; // more lines snipped break; }Robert Surtees writes We used to do it to piss off the "never use goto" zealots years ago when forbidden to use 'goto xit' for handling error conditions. And he's right. I could have done the same like this, with one few level of indentation:
if (set (ifrFragment)) { result = true; ifrTerm = ifrFragment; goto exit\_; } if (errorCode) goto exit\_; if (keyword (TokenSubtype::Not) && term (ifrFragment)) { result = true; ifrTerm = TokenSubtype::Not.asString() + " " + ifrFragment; goto exit\_; } if (errorCode) goto exit\_;// more lines snipped
exit_:So in the first example, I'm doing goto's -- without using them explicitly. Anyway, to get to my point: since different language have different control
A few years back, I maintained a project which used the "exit_:" construct quite a bit. Unfortunately, many had morphed into something like following (I included their abbreviations-which-make-no-sense to enhance the effect):
g3: close(hF1); if (i == 5) goto e1; e2: free pLS; e1: return;(With 'i', of course, being the counter from some loop and having some meaning other than array index.:))Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
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.
gotto agree with the exception you take to exceptions. A developer should NEVER rely on an error, this includes SQL errors from a stored procs. Coding by error is BAD - I recently offerred to sack a junior who wished to code in this method. Still promoting goto as a viable paradign should get you burnt at the stake as well, there are so many screw ups that have been attributed to badly formed goto!
Quote from Great Outdoors: its a confident traveller who farts in India
-
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.
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
-
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?
-
gotto agree with the exception you take to exceptions. A developer should NEVER rely on an error, this includes SQL errors from a stored procs. Coding by error is BAD - I recently offerred to sack a junior who wished to code in this method. Still promoting goto as a viable paradign should get you burnt at the stake as well, there are so many screw ups that have been attributed to badly formed goto!
Quote from Great Outdoors: its a confident traveller who farts in India
And the non-screwups attributed to properly used goto?
-
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;