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?

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.

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.

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).

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

Using Goto

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.

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.

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.

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

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

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

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.

-- 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.

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: 3 Aug, 2008 - 12:38 PM