I wonder why, after all of these years, there are still discussions, arguments, and even flame wars over goto, when 'everyone knows' that you shouldn't use goto statements.

The reason I think is that the anti-Goto brigade (of which I'm a fervent member) when posting, is aiming our comments at newcomers to programming. It's the pro-Goto people who often start the arguments by jumping in saying "you can use Goto" - when they haven't really read the post properly.

Instead, they should accept that it's not good practice, say nothing and continue using it if they wish to - rather than encouraging newcomers to use it.

I wouldn't dream of telling an experienced programmer not to use Goto as it is, as you say, OK to use it - if you have the experience to avoid the pitfalls. Unfortunately, most newcomers usually do not.

I still maintain that there's no place for Goto in a procedural programming environment, but I only say you shouldn't use it, not that you can't use it.

If someone can't write programs without using Goto, then it's usually because they haven't been told a better way to do it.

Many newcomers on here post code with problems wanting the more experienced coders to help them out. But, if they have used Goto, their code is extremely difficult to follow and personally, if I see it used, I'm a lot less likely to bother trying to help. Maybe others are the same - I don't know.

Most of your comments seem to echo what I said in my post, so I think we both more or less agree on the subject. And even if we did not, it's an emotive subject and everyone has their own valid opinion on the subject.

I will continue to point out to newcomers that the use of Goto isn't really the best way and point them to a better way to do it. After all, Functions and Procedures were introduced specifically to alleviate the problems caused by using Goto.

Incidentally, there now seems to also be a rise in the number of posts from people saying you shouldn't use Gosub and you should always use functions instead - though I don't see the logic in that argument...

TDK_Man

The reason I think is that the anti-Goto brigade (of which I'm a fervent member) when posting, is aiming our comments at newcomers to programming

I understand that, but the problem with that approach is that when you say 'don't use goto' the newcomers pick that up and just repeat it. There's no 'why' to it - just 'don't'.

Perhaps a better approach is to say 'there's no need for goto here because of a, b and c', or 'the do...loop structure does what you are doing there with goto', or 'just put an if around that code instead of jumping past it' (like in blastwave mans code above yours - thanks for the example BWM ).

If someone can't write programs without using Goto, then it's usually because they haven't been told a better way to do it.

I think I just agreed with that, at least for the most part
Connected with the problem is that newcomers to coding don't realise that when they are coding, they aren't just communicating with the compiler to produce an executable - they are communicating with themselves 6 months or more into the future.

Using a goto to implement a loop is almost invisible in the code. Using a do/loop, while/endwhile, repeat/until or for/next actually tells you something as soon as you see it.

do...loop: this is an infinite loop
while...endwhile: if this condition is true, execute the block until it isn't (execute 0 or more times)
repeat...until: execute this block until this condition is true (always execute once)
for...next: execute this block with an increasing/decreasing counter (execute a fixed number of times)
goto: who knows? Could be any of the above or none of them.

Using a goto instead of one of the loop constructs provides no benefits - you gain no speed increases, and you definitely lose readability.

Now for what I consider a legitimate uses of goto:
- exiting from a set of deeply nested loops.
- jumping to common error-recovery code.
- jumping to common cleanup code.

Note that these two uses of goto involve a jump forwards through the code (error recovery and cleanup are usually combined, so will be near the end of a function or subroutine), so won't result in spaghetti.

I can't ever remember using a goto to jump backwards through code (except maybe in batch scripts), and I can't think of any circumstances where I would do that, but that doesn't mean I won't do it if it makes the code clearer - I'd certainly add a comment of the fact that it jumps backwards.

Incidentally, there now seems to also be a rise in the number of posts from people saying you
shouldn't use Gosub and you should always use functions instead - though I don't see the logic in that argument

The only thing that I can think of (and it's the reason that my personal preference is to use functions) is that it's too easy to clobber your global and top-level variables by accident. I've also noticed today that duplicate labels are not spotted by the compiler - the last one in the code is used. Perhaps that's another reason.

I dunno, I've used subs in every game and/or application I've ever written, and never once has it caused any sort of conflict. Maybe it's in my format of naming variables, subs, and functions: at the expense of taking more time, I label everything not just to let me know what it's doing, but also to let me know where precisely it's used in my code. For instance, in another thread I was talking about the use of types and arrays. In that instance, the variable "resage" was the age on an applicant's resume. I very easily could have written "age" and have been done with it, but I find that the extra marking of where the variable is used keeps me from making mistakes down the road. But then that method definitely won't work for everyone, I can see how it would be more confusing to some. Anyway, that helps me avoid the duplicate use of a sub name, each sub is broken down by what it does in the game.

I understand that, but the problem with that approach is that when you say 'don't use goto' the newcomers pick that up and just repeat it. There's no 'why' to it - just 'don't'.

That's why I said in my above post:

"I'm not saying that you can't write a program using Goto - of course you can. You just don't need to!"

...and went on to explain why.

Now for what I consider a legitimate uses of goto:
- exiting from a set of deeply nested loops.
- jumping to common error-recovery code.
- jumping to common cleanup code.

And this is where we no longer agree. I would say that in procedural programming, there is no such thing as a 'legitimate' use of Goto.

But - and I have to stress this - I would in no way wish to convert you to my way of thinking. Call me a purist, but I'm happy to agree to disagree.

But, you have to admit that you can do all of the things in the above three examples even if you didn't have Goto right? There's just a little more work involved...

TDK_Man

god its like a coding religion
anti gotos!

Its like driving with one hand on the gearstick and only 2 fingers on the steering wheel. You CAN do it, it's just bad practice because it COULD destroy everything.

It could be used, but it's only useful in small, say 100 lines of code. If the code is getting bigger then you should restructure the code to take advantage of code reuse and use functions. 1 function does 1 job. If something breaks, you know which function it is and not have to worry about how may lines of code call a goto to that area.

Thats my very simple comments.