[NickDMax]

When I was first programming in BASIC I used goto and gosub all over the place. I didn't have function calls, and for next loops were (for me) only used for counting. So, I used goto.

Then one day I was showing someone a program I was proud of and he casually comments about spaghetti code (which my program really was). Within about a week a found a article on the matter and made a concerted effort to change my style.

Since then the only time I can think of using anything even LIKE goto would be using jumps in assembly language. This are actually amazingly formulaic and so more or less are structured.

Now, I don't think goto is evil, or terribly style -- but to me, it generally demonstrates an "immaturity" and is something that programmers eventually out grow. I hate telling people NOT to use it, because in my opinion there is nothing WRONG with using goto, it just a maturity thing. --- but recently I have been saying "DON'T DO IT" a good deal in the C++ forum... I think it is just a rash of people posting code with it.

Now I have seen some people who think it is funny to use JUST goto since it is "1337" -- such code has come in two catagories -- really really bad, and really really good. My guess is that those people that do the really really good code like that probably have normal day jobs and are just having fun.

What is your opinion on the use of goto? Should it be included in modern languages?

[Martyr2]

Nope, no need for it. I have always been one that believes if there is no reason to use it then you shouldn't. Anything that could use a goto could be coded another way and hence make goto useless. It really does violate program design and I am not saying that as some kind of "purist".

I do study the structure of computer languages a lot, much like a computer linguist of sorts and have never truly needed a goto in a modern language. I really wish they would just remove it altogether, even if it does result in breaking legacy code. That code should have been updated by now.

Goto also leads to the spaghetti code, it leads to the lack of readability and hinders maintenance. All reasons to be done with it.

[no2pencil]

If someone needs to use a goto statement, & they don't know a better way, then I guess use it. I do agree with you, that it is a style of programming that a developer should eventually graduate from.

Since all of my Basic programming was done years ago, I've long since forgot about using goto.

[NickDMax]

When working in FSM I have seen the use of goto in what I consider an acceptable manner. Sure the code could have been refactored to avoid the use of goto (none of MY FSM use goto) but I did find the code to actually be cleaner than my version which tends to have long blocks of if-else-if-else-if tied up in loops.

There ARE situations where goto is just the ticket.

Personally I think it should be left in modern languages... but not introduced in beginning programming books or programming 101 classes. (Though apparently people are learning from web tutorials these days... books are obsolete).

[AdamSpeight2008]

It still available in VB.Net
Would you consider the follow snippet as a local goto?
Using Exit

For i as integer=0 to 99
 If i=51 then Exit Loop
next i

Using Goto

For i as integer=0 to 99
 If i=51 then Goto ExitForLabel
next i
ExitForLabel:

[NickDMax]

Its a jump yes, but it is not the same as a goto. You can implement all of the control structures using goto... but we don't to keep the logic clean we have Control Structures. They keep the logic clean and keep us from shooting ourselves in the foot.

[Tom9729]

Usually the people who say "don't use goto statements" can't offer a reasonable reason to back it up.

Goto's do not lead to spaghetti code. Careless programming leads to spaghetti code. Suggesting that some language statement is to blame is ridiculous.

[DeCompile]

I've seen the goto function being used numerous times with 'walk in' programmers maintaining code.

As I've seen the core programmers have used 'partial' class files, it can take many hours to find the sub / function that they're chasing.

So to make quick fixes they will 'step out' of the code using an eg. goto 100 and step back into the code with a goto 10 after their code has run.

[KYA]

Why use goto when we have such elegant alternatives? (read: control structures)

[DeCompile]

Oh, I'm not condoning the practise of using goto.

I'm just saying, there are still people out there that use it.

[NickDMax]

There ARE people who use goto professionally. I have never really seen a situation in code maintenance where goto was really NEEDED but I have seen lazy people take the easy road out.

Quote

So to make quick fixes they will 'step out' of the code using an eg. goto 100 and step back into the code with a goto 10 after their code has run.

-- i.e. they used goto rather than a function call or inserting their code directly into the older code -- was goto the best solution to keep the logic clean, clear and maintainable? No.

Again I think this is a question of maturity -- in this case we are probably not talking about programmers who are just learning to program, but rather people who are new to code maintenance. Code is easier to maintain when it is clean and clear, and chances are the next time that bit of code is updated either someone else will be doing it OR (revenge is sweet) they will have to update it again and will have forgotten all about the changes they made and why they made them (well hopfully they documented what they did and put everything into a source control system... but if they use goto they are probably used to shortcuts).

i.e. using goto in code maintenance is no more professional than using it in original source code -- and no more excusable.

Like I said before -- there ARE situations where it is the perfect tool, but 99% of the time there are control structures that will make the code cleaner, clearer, and far easier to maintain.

[Martyr2]

Tom9729, on 2 Aug, 2008 - 01:08 PM, said:

Usually the people who say "don't use goto statements" can't offer a reasonable reason to back it up.

Goto's do not lead to spaghetti code. Careless programming leads to spaghetti code. Suggesting that some language statement is to blame is ridiculous.

Just wanted to make a few statements about this and the thread at large...

1) Well several reasons can be made not to use goto statements... check out Code Complete 2 by Steve McConnell page 398. He lists several including a reference to Dijkstra and his paper in March 1968 to the Communications of the ACM called "Go To Statement Considered Harmful" where Dijkstra himself lists problems with goto statements.

2) While McConnell does state disadvantages he does state some advantages too. However his end conclusion is that 99 out of 100 goto situations can be made more efficient and easier by using a goto-less approach, but does say that there are situations where a goto just might be of use. He said and I quote:

"In the remaining one case out of 100 in which a goto is a legitimate solution to the problem, document it clearly and use it. If you have your rain boots on, its not worth walking around the block to avoid a mud puddle. But keep your mind open to goto-less approaches suggestd by other programmers. They might see something you don't." -- Code Complete 2, Steve McConnell, page 407

This does back up statements Nick has made but it also flies in the face of the idea that goto is something that should be used regularly.

3) Goto statements are often put in by lazy and careless (sometimes lacking experience) programmers. Thus they tend to abuse it as a matter of bad habit and that bad habit and bad use of goto tends to lean towards bad code organization and results in spaghetti code. Goto isn't solely responsible for spaghetti code, but it certainly helps.

4) I love analyzing computing languages themselves and have seen endless lines of code and very very rarely do I ever see a goto. The ones I do see could probably have been avoided.

5) Lastly, if you ever find yourself making tons of nested if statements in an attempt to get around a goto, this just means you are not using other design techniques out there that can reduce this problem.

This post has been edited by Martyr2: 03 August 2008 - 12:38 PM

[NickDMax]

Quote

5) Lastly, if you ever find yourself making tons of nested if statements in an attempt to get around a goto, this just means you are not using other design techniques out there that can reduce this problem.

Hey I resemble that remark!

You are of course correct. There are OTHER ways to make FSM's (many of them are truly atrocious logic -- function pointers mixed with jump tables are probably worse that goto -- then again most such atrocious code is generated by a tool and not meant to be maintainable by humans).

This post has been edited by NickDMax: 03 August 2008 - 03:11 PM

[perfectly.insane]

I think there are some perfectly acceptable cases for the use of goto (other than code generated by programs). One shouldn't need to use goto very often, but it seems that there may be cases where the most elegant solution to the problem is with goto. Note, there are other ways to write these:

for(...) {
    REINTERPRET: switch (...) {
        case X: .....
        case Y: doSomething....; goto REINTERPRET;
    }
    
    // Other code....
    // .....
}

Another common case...

if(!someFunction()) {
     cleanupStatement1;
     cleanupStatement2;
     cleanupStatement3;
     return X;
}

if(!someFunction2()) {
     cleanupStatement1;
     cleanupStatement2;
     cleanupStatement3;
     return X;
}

if(!someFunction3()) {
     cleanupStatement1;
     cleanupStatement2;
     cleanupStatement3;
     return X;
}

In some cases could be more maintainable as:

ret = something;
if(!someFunction()) goto cleanup;
ret = something_else;
if(!someFunction2()) goto cleanup;
ret = something_else_else;
if(!someFunction3()) goto cleanup;
ret = 0;

cleanup:
     // No more repeated statements
     cleanupStatement1;
     cleanupStatement2;
     cleanupStatement3;

return ret;

Not that these are always applicable, and I usually don't do things like this myself, but I do think that when used carefully and thoughtfully (which applies to most other programming language features), that goto can be used responsibly.

[AfterBurner66]

In my opinion goto, was used in an era of programming immaturity, in a computer world immaturity, when all that programmers wanted was to create something that worked for one instance without a care about how to maintain or improve it in the future.There wasn't a certain methodology, for program and software development, programs were big enough,and particularly complex and this had the effect of spending a lot of time for source code development, debugging and maintenance, and the use of goto was playing a major role in all this. These were the factors that finally, revealed the need of another logic or structure of programs.Bohm and Jacopini, were the first that presented the notion of elimination of goto and the replacement of goto statement with the three kinds of structures
(sequence, choice, repetition), in a conference in Israel in 1964. But nobody cared then. After some years, Dijkstra pointed out the same thing.But the new logic began to gain acceptance,after many years. The truth is, that goto is a weak statement without any kind of programming logic.I think that is very analogous to eating every day from a fast food.
It is absolutely guaranteed that some day, you'll have health problems.
I don't say that goto is evil, but I do think that is a statement that can no more be taken seriously by a programmer.The structured approach is far more compact and the combinations that offers are absolutely limitless. The program can be maintained or even improved easier by far. Program has no more non-connected parts. So I can't really see why use goto at any instance.