Why shouldn't?

[ayyasaran]

It has always been advised in the history of programming
not to use the goto statement?

But, I found it very useful in some situations.

Then, Why shouldn't the goto statement used in programming?
Can anybody give me some convincing reasons...

Thanks in advance.

Saran.

[peet]

the reson is that extensive use of goto and gosub will make the code unreadable. don't think there are any other reasons for it, but I think that is reason enough

[beachbum]

[peet]

LOL one of u'r better answers bum !

[Joacim Andersson]

Yupp, a bowl of spaghetti might be tasty but using goto statements isn't very tastefull at all (besides you don't get the meatballs with the code but you might feel like a meathead while you're trying to debug such code).

As you mentioned your self Goto statements are considered bad practice and you don't really need them.
You can always code around them so you don't need 'em.

The only acceptable cases in VB when you might use a Goto statement is with an On Error Goto Label statement but that's only OK because VB lacks any good error trapping mechanism (this has changed with VB.Net that supports Try .. Catch .. Finally blocks ).

Now whith that said has anyone used the template About Dialog that comes with VB?
If you have, have you ever looked at the code behind the System Info button?
Microsoft do use Goto statements extensively in there (bad, bad dog! Go sit in the corner).

Best regards

[Tygur]

Nice illustration, beachbum.

If you avoid GoTo, your code will be much easier to read later.

I actually used to like GoSub (works similar to GoTo except you can skip back to the spot you came from), but I eventually stopped using that too.

[Joacim Andersson]

Yeah why would you use a GoSub statement when you have the power of true Sub routines and functions?

[Tygur]

Actually, there are some reasons. For example, a separate subroutine wouldn't share the same variables. You'd have to pass them over to the other subroutine or declare new variables there. That's more work.

[Joacim Andersson]

Originally posted by Tygur
Actually, there are some reasons. For example, a separate subroutine wouldn't share the same variables. You'd have to pass them over to the other subroutine or declare new variables there. That's more work.

I can't say that I would consider that to be a reson to use spaghetti code.
If you need to call the same code several times in one procedure you either create a new procedure, with the extra offer declaring new variables, or you use a loop.
Never use a GoSub or GoTo statement.

[WorkHorse]

Back in BASIC and Logo, everything was GOTO THIS and GOSUB THAT - what a mess! Subs and functions have replaced the old Gosub...Return. Although gosub can seem handy, it's really just a lazy sub.

The goto statement wasn't even very good programming in BASIC. Goto was basically used to leapfrog lines of code (there was no Else in the If...Then statement, let alone Do, While, Wend, Select case, etc.). Goto usually sent the code scrambling around like a kid on easter egg hunt with adults pointing in all directions. Goto leaps out of your code and runs off to do something entirely different. The only time you should want to just jump out of the middle of your code, is if an error occurs.

Goto and Gosub are old BASIC hangers-on that have been replaced by other coding methods and are headed for retirement.

[Tygur]

Originally posted by WorkHorse
Although gosub can seem handy, it's really just a lazy sub.

Exactly, and I was a lazy programmer. That's why I used to use it.

Originally posted by Joacim Andersson
I can't say that I would consider that to be a reson to use spaghetti code.
If you need to call the same code several times in one procedure you either create a new procedure, with the extra offer declaring new variables, or you use a loop.
Never use a GoSub or GoTo statement.

I agree with you, but I didn't always think GoSub was so bad. I recognized the problems with GoTo right off, but I kept using GoSub for a while.

[WorkHorse]

One thing I like about GoSub that I can't quite seem to duplicate in VB is that you can nest the GoSubs into a function and then just have the one function to deal with.

For example: You write a function that does some common function that you use in a bunch of projects. At several points in the function it is running the same code, so you throw that code into a Sub and just call the Sub. Now you have the function plus, say, 4 Subs. To use the function in a project, you have to copy in the function and make sure you also copy in the 4 subs. These all start cluttering up the code window. Those 4 subs don't have diddly to do with the rest of your project - they are only used for your function. If you use GoSub instead of actual Subs, your function is one nice neat travelling package.

Is there a way to get all related subs (those that are only used in connection with one another) packaged together so you just have one thing to deal with. Should those all be put in a separate module or something?

[Tygur]

I would put them all in a separate module that can just be dropped into any project. Just make the functions and subs that are unrelated to the rest of the project private.

[beachbum]

Yeah i know what u mean WorkHorse. I guess a sep module or class module is appropriate in that circumstance but i have done what u talk about in modules and 'wished' for some way of linking such related functions or even some form of groovy styling so that u can see that the items are locked together... in the end i just use '---- line separators and exageratted indenting...

I would still prefer this to GoSubs tho. when i first started programming, everything was GoTo's but then again everything was procedural. I guess that if u force yourself to stick to a structure then u could more easily follow and debug goto's. i dont think tho that the problem of structure and organisation has gone away with current subs and functions... people can create a mess without trying too hard.