This use of goto

Unity Engine
1

Ok, Firstly, I am not religiously against using goto and I don’t want to get into a debate (read: flame war) on the general usage of it. But having had to modify code in the past (non Unity stuff) that had it all over the place I am aware of the many pitfalls of its use. Spaghetti code is not nice to debug and modify.

However what do you guys/girls think this small usage:

IEnumerator ChangerRoutine()
    {
        Start:

        int count = Items.Count;
       
        for (int i = 0; i < count; i++ )
        {
            TargetText.text = Items[i];
            yield return mTimer;
        }

        if (Repeat) goto Start;
        mRoutine = null;
    }

It is a coroutine that just loops through a list of strings and sets a text element to the next one every x seconds. This can be repeated or not based on the component settings. I was considering wrapping the whole thing in a while(repeat) loop but for some reason this way just feels more explicit.

Am I just being stupid here? And should I just use the while(Repeat) style?

2

I don’t see why you wouldn’t use a while loop in such a straightforward case. When another programmer starts reading this function (and don’t forget, You-In-Six-Months is very much “another programmer”), a while at the top will be explicitly clear as to the intention of this coroutine. “Start:” could mean anything.

If the flow was different it might be sensible to use goto, but it’s tough thinking of examples where goto is a good idea because it so rarely is.

3

Yes, just use a while loop. The only real example I can think of where goto makes sense is breaking out of a nested loop, since other methods end up being more convoluted.

–Eric

4

I’ve used goto’s in coroutines numerous times.

The suggestion of readability may be of a concern.

But in the same respect, readability is directly correlated to the expectations of the reader. As someone who has read a LOT of code with properly maintained goto commands, I wouldn’t find them to be unreadable. I too am not religiously against them as long as they’re used correctly… and C# doesn’t really allow you to use them incorrectly, it’s not a jump command that would let you leave the scope of the operating function.

So… who maintains this code? Who do you expect to maintain this code in the future? Are you and those people capable of understanding the intent of well formed goto statements?

Because functionally… it’s not big deal. Functionally, a while statement IS a goto statement when compiled into IL.

This guy actually breaks down most of the loop statements and shows the correlating IL:

5

Theres no need for using goto except lazy programming.

6

Because that’s not flame war fuel.

1 Like
7

I’ll goto the lock button while monitoring this thread.

8

That looks about as readable to me as a while loop would, not sure what the issue is.

9

IMO it’s better to do this…

            while (something)
            {
                // do stuff

                if (condition) break;
            }

… Because the loop condition is always at the top and the break conditions are always inside or at the bottom. Read conditions, find dead ends.

Alternatively you would follow the code, run into a goto, then need to leave where you are currently at find that label target to continue flowing through. However, if you were using while and break you would hit dead ends on conditions and its a lot easier to navigate more complex routines because the reading flow is much more linear, predictable and consistent.

Whatever you decide to do - be consistent. You don’t want to deal with changing your flow habits unnecessarily. If you can organize your code to make the goto stuff work for you and you want to do it, go for it.

10

Its not a flamable comment. Its honest. If you were in my team and tried to put a goto into the code I would kick your ass. I just dont think there is any justification for using it. Its nasty to maintain if abused.

There are plenty of thinly veiled goto statements that are not goto. (continue/break/early return, etc)

also, doesn’t goto break performance in regards to code execution prediction. Im sure I read something about it years ago when it was relevant.

11

Aww, ok… so you just don’t like them.

And you have a standard as the lead of your team that they’re not allowed.

Totally legit. Hence in my post I mentioned the whole, will anyone maintaining your code in the future be able to read them fine. As a lead you need to consider these things.

But you do understand that when you go from “I don’t like them, so I don’t use them on my team”, to blanket calling anyone who uses them “lazy”. Not just that, you don’t even offer anything to the discussion, but just to call anyone who uses them lazy. Well, that is flame war fuel. You’re calling other programmers, not on your team, lazy.

Could you not see why I, or other programmers, might be like “wait a second, I’m not lazy… and you didn’t give any justifications beyond ‘its my feeling’ or ‘i don’t think’…”.

flame war fuel

2 Likes