Sometimes, you create a coroutine and then call it somewhere else, you forgot to use “yield return” or “StartCoroutine”. There is no warning or errors. Is there a quick way in Visual Studio Code to raise warnings for such mistakes?
Hmmm no. Typically, if that‘s the issue you‘re having, you are likely overusing or misusing coroutines. 
I rarely, if ever, have more than one active coroutine per MonoBehaviour.And it‘s very often short-lived, like delaying something to the end of frame because you can‘t run it in OnValidate or you want to complete a job.
For everything that‘s state-based, coroutines are a crutch. Manually checking time in Update and a Statemachine are superior tools for such jobs. And for timing more complex things we have Timeline.
You can start getting errors from that if you add this to the end of your .editorconfig file:
# UNT0012: Unused Unity Coroutine
dotnet_diagnostic.UNT0012.severity = error
The .editorconfig file is found at the root of your project folder, and can be opened for editing with Notepad, for example.
2 Likes
I just like to add that IEnumerators are nothing specific to Unity and as such not EVERY enumerator can or should be passed to StartCoroutine. Enumerators and Enumerables are actually used to iterate over “things”. So there’s barely any “correct” usage without knowing the purposed of the IEnumerator. The compiler can’t know or understand that purpose without some kind of advanced AI analysis. Yes, it’s possible to emit errors when you ignore the return value of your generator method which indeed doesn’t make much sense. However technically it’s never an error to ignore the return value of a method. Logically it makes no sense in the case of IEnumerators but that’s up to you. Theoretically you could have a method returning an IEnumerator that actually has some useful sideeffects and you may ignore the return value. Though that would be a strange approach.
Yes, the compiler should support you to avoid errors. However when it comes to logical errors that’s mainly up to the programmer.
3 Likes
Absolutely agreed with Bunny. Sometimes I write iterator methods and they have nothing to do with coroutines and it would be really annoying/weird if I got an error or warning for doing that.
1 Like
Well, luckily every programmer / team has the ability to configure the severity level for all these rules to fit their preferences 
Nowadays it is also possible to explicitly tell the compiler - and everyone who reads your code - that you are intentionally ignoring the return value of a method:
_ = LogErrorIfCurrentCoroutineIsNotNullAndReturnIt();
Since this is a possibility, I think it makes a lot of sense to get an error if you execute a method that returns an IEnumerator without doing anything with its return value. I don’t remember ever in my life writing method that returned a non-generic IEnumerator that wasn’t a coroutine or an implementation of IEnumerable.GetEnumerator (though it could be I’m just blanking out right now).
For the rule against ignoring return values in general, I’m not using error/warning severity level at the moment. I would find it a bit irritating to have to use a discard every time I wanted to ignore the return value of List.Remove, for example.
I do however sometimes add the PureAttribute to methods, so that the compiler will be able to show an error if the return value is ignored in these situations where it should never be done. I tend to do this with all methods in utility classes, as well as with methods that return a new value instead of modifying the original one passed to the method, when this fact is not necessarily clear as day (like, let’s say an InsertAt extension method for T[ ]).
1 Like
How about a source generator? I was looking through suggestions by ChatGPT and that one came up but I’ve only just started reading up on them and I have no idea how to build one yet or if it even is correct and not hallucinated.
I was thinking you could search for all methods that have a certain prefix or suffix in addition to the IEnumerator.
