[RESOLVED] What is wrong with GoTo

[chris128]

I've seen a few people on here saying that you shouldnt use GoTo in VB.NET and to be honest I've tended to agree as I have never needed to use it and there is always another way of doing something without using it.

However, I'm just wondering what is so bad about it? I actually noticed that Microsoft seem to use it a fair bit in the internal .NET framework code, which is what makes me wonder why people are so against it.

Cheers
Chris

[jmcilhinney]

Like so many things, GoTo is not inherently bad but it just has a tendency to get abused. As you say, there are always other ways to do things so why not use them. If you use GoTo then you have to be disciplined to not create spaghetti code. It really doesn't take that much discipline but why require any if you don't need to, plus the fact that some people just don't have any to begin with, so why tempt fate?

[gep13]

Hey,

I am certainly by no means an expert on this topic, but my understanding would be that they are a bad practice and should be avoided. This is because you can end up in a situation with "spaghetti" code, where you are jumping all over the place. This results in code that is hard to read and difficult to maintain.

Will be interesting to see what comes out of this thread though.

Gary

[chris128]

Thanks for the replies guys, I did think that might be the only reason but just wondered if there was any actual technical reason to avoid using this (performance or otherwise).

So its a good idea to avoid using it purely to keep code tidy and readable right? No other reasons


By the way I'm not planning on actually using it anywhere so I'm not looking for someone to say its ok to use it, I am just curious

[FunkyDexter]

As JM said, it's not it's bad in and of itself but it does tend to lead to spaggetti code. I was trying to think of why is pastas your code, though, and I think it's because it's uncontrolled. You can send someone anywhere at all in the code with no guarentee of where (if at all) they'll return to. Back in the days of line numbers rather than labels it was really insidious because you couldn't even be sure you'd be sending them to the right place (sooner or later some bright spark would think it was a good idea to renumber your code and the whole thing would collapse in an irrecoverable heap).

[RobDog888]

The only place it was justified to use it in was in VB6 error handling. In .NET we have Try Catch error handling and thus no need for GoTo's.

Oh the GoTo xxxx line number technique of BASIC from "back inthe day" Oh the memories.

[chris128]

The only place it was justified to use it in was in VB6 error handling. In .NET we have Try Catch error handling and thus no need for GoTo's

So why is it used quite heavily in the .NET framework itself? (You can see from disassembling the .NET framework DLLs using something like Reflector)

[jmcilhinney]

So why is it used quite heavily in the .NET framework itself? (You can see from disassembling the .NET framework DLLs using something like Reflector)

I've asked myself the same question as I've seen it many times in Reflector. Maybe they made a policy that GoTo can only be used to jump to labels later in the code, which would avoid spaghetti code. I still don't think it's a good idea though.

[chris128]

Yeah I guess that must be the case as thats the only time you see it... oh well, I'll still probably never use it myself but at least now I know why its best to avoid it

Thanks

[RobDog888]

Oh I thought we were talking about user created code and not in the FW.
We cant write the FW code, well we shouldnt unless we get paid by MS lol.

[chris128]

Well yeah I was talking about user code but I just mentioned the fact that MS did use GoTo quite a bit in the FW code which is what made me question why I shouldnt use it.

[RobDog888]

Well we shouldnt duplicate bad coding practices unless there is a valid reason for it. Im sure MS used it for some good reason, perhaps they wee forced to use it. :shrug:

[techgnome]

I find that a bid odd... seeing as how the FW was written in C# ... not VB. Are you looking at actual FW code? OR are you looking at disassembled code? Correct me if I'm wrong, but it could be that Reflector is putting it into "VB" since that is what you are using. I've been through some of the actual FW code, and can't think of a single time it used a GoTo. But then like I mentioned, GoTo is a VB language construct, not C#.

-tg

[RobDog888]

Good point TG. If you used reflector in C# what would you see...

[chris128]

I find that a bid odd... seeing as how the FW was written in C# ... not VB. Are you looking at actual FW code? OR are you looking at disassembled code? Correct me if I'm wrong, but it could be that Reflector is putting it into "VB" since that is what you are using. I've been through some of the actual FW code, and can't think of a single time it used a GoTo. But then like I mentioned, GoTo is a VB language construct, not C#.

-tg

I'm using Reflector to view it but even when setting the language to C# in reflector it still shows GoTo in the same places

MSDN seems to say GoTo is perfectly valid in C# as well... http://msdn.microsoft.com/en-us/library/13940fs2.aspx

[RobDog888]

I cant belive they posted that page
Even look at the posted comment lol.

Maybe they did it to cover their "you know whats"

[Max Peck]

Like most everything in software development it is a matter of opinion as to whether using a particular construct or feature is a good or bad thing.

GoTo can sometimes be a solid, direct way to control program flow in a simple manner when performing complex gymnastics on if/else clauses would make understanding the code more difficult. OTOH, GoTo when used without any discipline can (as has been alluded to) yield horrible "spaghetti" code.

As always, it is up to the individual developer to set a standard for elegance when they write their code. Goto is no worse or better a feature than anything else - it is simply a tool. In my 35+ years of development I've seen good and bad procedural code, good and bad OO code and everything in between. The language is the language - misuse of the tools is where the problems develop. Poor (or complete lack of) design can produce spaghetti with or without the much maligned GoTo.

To take the dogmatic position that GoTo is either good or bad (whichever "side" you choose) is foolish.


-Max

[chris128]

Why cant you believe it?

[chris128]

Max Peck - I agree but some methods or keywords etc have an alternative that is actually technically better. Some are known to give bad performance or have bugs in or whatever, which is why I was asking about this particular item - to see if there was any technical reason not to use GoTo

[Shaggy Hiker]

Under the hood, we all use GOTO. After all, it just maps to a jump command, which is a part of every If statement. For that reason, every If statement, and every loop, can be re-written using GOTO. It would probably be possible to enforce some kind of structuring on GOTO targets such that all loop and If statements could be replaced by GOTO. It wouldn't be clear, though, and would take on the opacity of ASM.

[chris128]

Does it just end up as the JMP assembly instruction when executed by the CLR then? I suppose it does work in the exact same way but I hadnt considered that it just literally 'translates' to that same command

[techgnome]

Is there a technical reason? No. It's probably one of the least costly instructions - a simple jump. However...

Since moving to VB, the number of times that I have found GoTo to be necessary (excepting On Error) ... has been exactly nil.

The problem is that maybe there's that one time out of 1,000 where it is "necessary" ... but it's that 999 other times where it is misused... and BADLY misused that gives it a bad rap. I have the same feelings about On Error Resume Next... to me that's just a horrible thing to do. But others claim otherwise. Meh, what ever boats your float.

My personal opinion and experience is that nothing good can come out of a GoTo and that it should be avoided at all costs. It was a necessity back when there were no such things as procedures... when it was the only way for program control.... that is no longer the case. If it were up to me, I'd have it axed from the lexicon. But that's just me.

-tg

[jmcilhinney]

Yeah, GoTo really is a historical remnant. It was originally a part of pretty much all languages but has really outlived its usefulness. C# is based on C/C++ so it inherits its goto statement from there. The only time it was of genuine benefit in VB.NET that I'm aware of is when you wanted to skip the rest of the current iteration of a loop and go back to the beginning. Now we have the Continue statement but previously you had to use a GoTo with a label at the end of the loop. You could just use If statements but that could lead to some rather deep nesting. C# has had 'continue' from the start I think, so 'goto' was even useful there.

[David Anton]

It's all a matter of degree - GoTo is at one extreme, but note that there are many "slightly sanitized goto's":
Continue For
Continue Do
Continue While
Exit For
Exit Do
Exit While
Exit Select
Return / Exit Sub / Exit Function

Someone expressed surprise at goto being in code generated by reflector for C#, but 'goto' is valid (although not recommended) C# syntax. Note that most languages have 'goto' - the only popular programming language that omits it is Java (it just has the sanitized versions: continue, break, and return).

[techgnome]

but those are specialized... they have a purpose... and you can't just stick them any ol' place you want. They are part of a larger structure. The destination of GoTos are arbitrary... Continues, Exit and Loop aren't.

-tg

[Shaggy Hiker]

Technically, you can add If, For, and Do into that list, because each of them causes a jump, as well. In other words, I agree with TG.

[RobDog888]

My personal opinion and experience is that nothing good can come out of a GoTo and that it should be avoided at all costs. It was a necessity back when there were no such things as procedures... when it was the only way for program control.... that is no longer the case. If it were up to me, I'd have it axed from the lexicon. But that's just me.

-tg

Same here