Since goto is getting so popular these days....
-
I get that this is a joke question, but seriously, why so much debate about it? It messes with flow in a pretty unreadable way, and the whole point of modern (post 1950) computer languages is that you write for your colleagues (or your future self) so why do it? But we've all seen a lot worse[^], so goto isn't the devil incarnate... end of story(?)
"It messes with flow in a pretty unreadable way"? Really? You find a goto statement unreadable? It really doesn't get much easier to understand than a goto statement. As easy, or easier, than a function call (a function call could be in a place further away in the code, and thus slightly harder to track down, while a goto, if not done poorly, will be very close by.) This gets pretty silly. There's nothing inherently wrong with goto. This comes from efforts in the distant past to clean up spaghetti code - one of the tenets of "structured coding". From wikipedia: "Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed (and still disagrees[citation needed]) with abolishing the GOTO statement. In his 1974 paper, "Structured Programming with Goto Statements", he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing provability." There's another "rule" to have only 1 exit point from a procedure. Yet this can lead to badly structured (unreadable, unmaintainable), deeply nested if statements, especially where return code and error handling are concerned. Lacking a quick "return" call, I think a "goto" to an exit line would be appropriate. switch statements are glorified gotos, as are multiple return statements (just debug the procedure if you doubt that :-) )
-
Ignore people who say goto is bad. Don't use goto when it's bad. It should be clear to you when that is. Don't use goto when there's already a language construct that can be used *just as easily*. One place where I use goto without apology is to simulate a finally clause when exception handling is not part of the language, or is non standard. For instance, in C. It's a matter of style, but I prefer the second version below: BEFORE:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) { .... error = somefunc2(...., &r2); if ( !error ) { .... error = somefunc2(...., &r3); if ( !error ) { .... free( r3 ); } free( r2 ); } free( r1 ); }}
AFTER:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) goto error: .... error = somefunc2(...., &r2); if ( !error ) goto error: .... error = somefunc3(...., &r3); if ( !error ) goto error: ....error:
if ( r1 )
free( r1 );
if ( r2 )
free( r2 );
if ( r3 )
free( r3 );
}Yes, the second form can be constructed without the goto, by using a gated if along the way, but having all the clean up code in a single place is a nice feature.
That is a perfectly acceptable use of goto, as I mentioned in an earlier reply as well.
-
Jon Sagara Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big. -- George Carlin .NET Blog | Personal Blog | Articles
Ahahaha!! I couldn't imagine a better fate. Do loop breaks also beg for a dinosaur attack, or is that more of a dozen-rats-at-your-ankles sort of offense?
-
"It messes with flow in a pretty unreadable way"? Really? You find a goto statement unreadable? It really doesn't get much easier to understand than a goto statement. As easy, or easier, than a function call (a function call could be in a place further away in the code, and thus slightly harder to track down, while a goto, if not done poorly, will be very close by.) This gets pretty silly. There's nothing inherently wrong with goto. This comes from efforts in the distant past to clean up spaghetti code - one of the tenets of "structured coding". From wikipedia: "Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed (and still disagrees[citation needed]) with abolishing the GOTO statement. In his 1974 paper, "Structured Programming with Goto Statements", he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing provability." There's another "rule" to have only 1 exit point from a procedure. Yet this can lead to badly structured (unreadable, unmaintainable), deeply nested if statements, especially where return code and error handling are concerned. Lacking a quick "return" call, I think a "goto" to an exit line would be appropriate. switch statements are glorified gotos, as are multiple return statements (just debug the procedure if you doubt that :-) )
I don't think there is an inherent problem with goto, but it comes with a high potential for abuse. Goto tends to be employed to get around a logic problem. By circumventing program flow, these gotos tend to interfere with scalability. It is the Scooby Doo ending of the coding world. Stick a rubber goto mask on the only other human in the episode and blame those pesky kids.
-
I don't think there is an inherent problem with goto, but it comes with a high potential for abuse. Goto tends to be employed to get around a logic problem. By circumventing program flow, these gotos tend to interfere with scalability. It is the Scooby Doo ending of the coding world. Stick a rubber goto mask on the only other human in the episode and blame those pesky kids.
I guess I have a problem with saying things like "By circumventing program flow..." goto doesn't "circumvent" program flow, it IS program flow. That would be like saying functions and if statements "circumvent" program flow. They direct program flow as program flow must be directed. If it's directed incorrectly or confusingly, that's not a problem with a language construct, it's a problem with the algorithm or program design. It really doesn't get much easier to understand than "goto MyLabel;" If you can't read and understand that, you simply can't understand code or follow directions.
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
you WILL use goto in any non-trivial batch file as a quick-and-dirty solution to a simple syatem problem (or just maybe you have moved on to Powershell or Python or whatever so can prove me wrong). Back in the old days, before exceptions, you might very well use GOTO in recovering from certain kinds of error conditions. This was especially problematic on the venerable Apple II which did not properly unwind the stack in these situations. In one application I had to save relevant state and decide on which point to re-enter the program to sensibly resume - I managed this without the spaghetti falling off the fork (as it were).
-
I guess I have a problem with saying things like "By circumventing program flow..." goto doesn't "circumvent" program flow, it IS program flow. That would be like saying functions and if statements "circumvent" program flow. They direct program flow as program flow must be directed. If it's directed incorrectly or confusingly, that's not a problem with a language construct, it's a problem with the algorithm or program design. It really doesn't get much easier to understand than "goto MyLabel;" If you can't read and understand that, you simply can't understand code or follow directions.
In addition to arguing semantics, I think you followed up on a lot of points I didn't make. Introducing a goto is usually employed as a quick fix that interferes with scalability. I don't think there is any debate there.
-
GWBasic was cool. I did an awesome app in it wayyyy back in the day.
Everything makes sense in someone's mind
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
-
Yes, it was cool. Equally cool was IBM Compiled BASIC. When I first got my IBM PC (1983) I wrote a text editor in it. The thing still runs in a DOS session under XP! Unfortunately it doesn't run in the Win7 DOS box any more. -Max ;-)
When I was in college I worked managing a Mini Storage for a friend. All their records were on paper, and it was a mess. So I wrote an app in GWBasic to manage customer accounts. For have little to no experience it came out awesome. I still have it on a 3 1/2 floppy. Ahh the good ole days.
Everything makes sense in someone's mind
-
In addition to arguing semantics, I think you followed up on a lot of points I didn't make. Introducing a goto is usually employed as a quick fix that interferes with scalability. I don't think there is any debate there.
Well, let me ask you this. Have you seen a developer write a goto line in the last 5 years or so of reviewing code? The use of goto is so taboo that people just don't do it. So when you say it's "usually" employed as a quick fix, are you speaking from the experience of many examples, or are you just restating what you've read somewhere? Because frankly I don't know anyone who has personal knowledge of a lot of gotos in actual use these days. People freak out so much when they see it in a code review, that no one codes it anymore just because they don't want to deal with the backlash.
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
I cannot sit idly by and watch the world go the hell in a handbasket at the hands of these self taught millions who comprise the new generation, what is it, generation Y? I say call it Generation Why? Why in the world are they doing it this way? Why would a well known cardinal rule end up being an urban legend? - the "goto" This is not good. I would recommend posting a copy of your code to this discussion board so we can confirm that the placement of the words form the shape of the antichrist. God help us all.