A little survey. Would a code checker tool that points out ECS-specific errors be useful?

[latent thorn]

Hey, guys! I am a C# developer but not from the gamemade sphere. At work I am developing one static code analyzer. I study Unity as a hobby, hoping to realize something working and cool one day 🙂

In order to have enough time for everything, I want to combine hobby and work somehow. This aspiration gave birth to the idea of analyzer's warning scripts specific for Unity, which I try to promote at work.

Now I'm studying ECS and it seems that there are a lot of non-obvious points in this approach. A lot of things Unity has thought about and handled with appropriate warnings in the inspector, but not everything. Plus, these warnings are usually only shown when the problematic code is executed.

And in general, I would like to know the opinion of real Unity-developers. Could a code analyzer taking into account ECS specifics make code writing more efficient?

Just for example, we could make warnings indicating:

• that [BurstCompile] is used where it is not supposed to be used or on the contrary is not used where it could be used
• Bake performs state saving, e.g. by writing to a field;
• Bake uses data from a component other than authoring, but this component is not passed to DependsOn.

This is the first thing that came to mind, I think if you go through the documentation, you can find a lot of such nuances.

[upper violet]

I know a lot of us use Rider, which adds a lot of static code analysis and it's super useful. So probably would be useful to have that for those who don't use rider, or to have more than what rider shows.

[undone osprey]

Analyzers is one thing, I think code fixes will be equally important. Sadly Rider still doesn't support Roslyn CodeFix which is pretty annoying to me.

[latent thorn]

Our analyzer does not have an auto-correct function either. This is because it is likely to work very poorly. To fix some small simple misprints is one thing, but to fix something more complicated, for example, NullReferenceException, is quite another.

For example, the analyzer may add checking a variable for null as a solution. But what if this variable should never be null in principle? In this case, auto-correction will only hide the problem, not fix it.

Besides, all analyzers give false positives because it is very difficult to take into account all possible variations of errors and their validation in diagnostics. If the analyzer makes corrections based on these false positives without your control, it will ruin the project rather than fix it.