goto [modified]
-
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; -
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.