How do you name your coroutines?

I personally dislike calling public coroutines directly from other classes. I rather do something like in the example below and just call a public method that then calls a private coroutine.

Code (CSharp):

1. public void Move (Direction direction)
2. {
3.     StartCoroutine (MoveRoutine (direction));
4. }
5.  
6. IEnumerator MoveRoutine (Direction direction)
7. {
8.  
9. }

The thing is, let's say move was fully handled from within the class, rather than called from another.
I'd just go ahead and name the coroutine "Move" rather than "MoveRoutine" since there'd be no use for the "Move" method.

Because of that, I end up with a bunch of "SomethingRoutine" for all coroutines that are called externally, and a bunch of "Something" without the routine part for the ones that are fully handled internally.

I don't really want to add "Routine" to everything. It feels like I'd have to add "Method" to all methods with void return type, and so on for right about everything.

How do you guys deal with this? I can't be the only one who dislikes calling coroutines from other classes?

 

I don't do anything special with my coroutine names personally, but I know there are some that will add something to them so they know it's a coroutine and they need to call it using StartCoroutine instead of just calling directly. Nothing wrong with that either.

Honestly. Do what is comfortable for you. If you have a team, you would want to set a standard. If it's just you, whatever works for you is fine.

I don't generally call coroutines from outside of the class, but I have and it doesn't really bother me any.

 

Alright, thank you. This makes sense. I guess I'll figure out a keyword so I don't end up with inconsistencies.

I have never worked with other programmers, but I would like that some day. Since I've learned in such an isolated environment, I'm always living in fear that there is an obvious standard for certain things I'm doing that I'm fully unaware of.

 

I name my coroutines like this

Code (csharp):

1.  
2.  
3. // public IEnumerator Obsolete() { }
4.  
5.  

 

This is the kind of stuff I'm talking about. I'm guessing that was an obvious joke and it went miles above my head. Why are coroutines considered obsolete?

 

I currently don't append anything to the name of coroutines in my own projects, as the name is usually descriptive enough and the coroutines are mostly implementation details. But I'll probably change that in the future during some major refactoring process. Not sure what I'm going with though.

When I'm working in teams, e.g. at university or at work, we usually append something, because it's more important to quickly understand what's available. I mean, within a script, it's usually obvious when you call StartCoroutine or yield a method.

But that differs alot from project to project, sometimes also due to the functionality or its implementation details.

 

Thank you for your answer, it's appreciated.

 

Perhaps in regards to .NET 4.6 compatibility, more specifically async/await.

There have been alot of discussions about whether or not async-await is able to replace coroutines. It is indeed possible even though that's currently not the original purpose (as stated by the devs themselves), but the current default behaviour provided by the engine seems a little odd anyway (unless this has changed meanwhile).

Nevertheless, backwards compatibility is often desired, that's why I personally don't feel like they're obsolete. Many plugins and old code-bases are written in favor of coroutines anyway. So they're gonna be a relevant subject either way. Should be a part of every serious Unity user's toolbox.

 

You're very knowledgeable, I appreciate your input. Thank you, once more.

 

I do it just like you.

 

I keep coroutines private because it's too easy to forget to add a StartCoroutine, and instead try to call it directly like a regular function. Then you're left wondering why the app is behaving oddly until you discover the missing StartCoroutine directive :/ Or worse yet, have users forget to add a StartCoroutine, then send bug reports to you, making you spend your own time figuring out WTF is going on...

So, I'm the same way -- have a public function that calls StartCoroutine for you. That's one nice thing about async/await -- if you forget an await, the compiler yells at you.

I'd still name the function in a certain way to make it obvious that it's some long running thing that will finish n frames later. Usually "BeginProcessing" or something is sufficient.

 

I need this especially when I need to start a coroutine triggered by an event. I'll be happy to see if there is a better way. This looks repetitive especially if no initialization is required.

Code (CSharp):

1.  
2. void Awake ()
3. {
4.     OtherClass.OnSomethingHappened += Move;
5. }
6.  
7. void OnDestroy ()
8. {
9.     OtherClass.OnSomethingHappened -= Move;
10. }
11.  
12. void Move()
13. {
14.         // Maybe some initialization if needed...;
15.         StartCoroutine(MoveRoutine());
16. }
17.  
18. IEnumerator MoveRoutine()
19. {
20.  
21. }

 

I add a leading underscore, C-style. Mostly for coroutines in the same class as potential callers:

Code (CSharp):

1. void performA(int parm1) {
2.   paused=true;
3.   StartCoroutine(_performA(parm1));
4. }

The line with paused is another reason I split them at all -- maybe what guneysan was getting at. In theory, a coroutine could start much later in the frame, and we may need certain variables set immediately. But, yeah, mainly because of the 3rd time I forgot the StartCoroutine and spent 5 minutes debugging.

 

Kinda late here, but I always start my coroutine with a "Do", such as "DoMoveToPosition." I really don't know why I do that specifically, but I based it on the premise that it implies looping and does tend to function a bit like a do-while loop, as most of the time there will be SOME aspect of the coroutine that's guaranteed to execute at least once. For me it also implies the action, but I could see someone writing a coroutine with "For", "While", etc., if that clarifies the looping nature of it. Am I crazy, or does anyone else do something like that?

Also as an aside, a number of people have brought up the clean ways to work with coroutines. I definitely agree that I NEVER make coroutines public and trigger them from a separate class, partly because it can be unclear on quick observation why your code is failing if you accidentally called the coroutine like a function istead of using

StartCoroutine

. I always make the class itself handle it, and use a public method if another class needs to do something to trigger it. That way, I can also have better control over it and use a syntax that allows storage of the executed coroutines. Example:

Code (CSharp):

1.     [SerializeField] private float coroutineDuration = 2f;
2.  
3.     private bool coroutineHasStarted = false;
4.     private Coroutine myCoroutine;
5.  
6.     public void FireOffCoroutine(bool interrupt)
7.     {
8.         if (!interrupt && coroutineHasStarted)
9.             return;
10.         else
11.         {
12.             if (myCoroutine != null)
13.                 StopCoroutine(myCoroutine);
14.  
15.             myCoroutine = StartCoroutine(DoExecuteCoroutine());
16.         }
17.     }
18.  
19.     private IEnumerator DoExecuteCoroutine()
20.     {
21.         coroutineHasStarted = true;
22.  
23.         float t = 0;
24.  
25.         while(coroutineHasStarted)
26.         {
27.             if (t >= 1f)
28.             {
29.                 //DO SOME TYPE OF COMPLETION BEHAVIOR
30.                 coroutineHasStarted = false;
31.             }
32.             else
33.             {
34.                 //DO SOME TYPE OF INCREMENTAL ITERATION
35.                 t += Time.deltaTime /coroutineDuration;
36.                 yield return null;
37.             }
38.         }  
39.     }

NOTE: I wouldn't necessarily structure my code in exactly this way for production, since some of the else statements, etc. are superfluous, but hopefully it makes a clear example.

It's also a good idea to use some type of variable to help determine if a coroutine is currently running, as simply checking if it is null isn't always reliable.