You should usually only call GetComponent<> in your Awake function, then cache the result in a strongly typed instance variable. This is widely known standard operating procedure with Unity.

IDEs like Rider will highlight and warn you about using GetComponent in performance critical contexts like your Update method.

https://blog.jetbrains.com/dotnet/2019/02/21/performance-ind...

>Unity has a number of methods that get called very frequently. For example, MonoBehaviour.Update is called every frame, as is LateUpdate, and FixedUpdate can even be called multiple times in a single frame. Rider treats all of these methods as performance-critical, and will highlight the method in the editor gutter.

[...]

>Once inside a performance-critical context, Rider enables a number of inspections:

>Avoid usage of GetComponent methods

>Avoid usage of Find methods

>Avoid usage of AddComponent

>Avoid string based method invocation (Invoke, SendMessage, etc.)

>Avoid Camera.main

>Avoid null comparisons for Unity objects

>The links above will take you to the documentation pages for each of the inspections, which provide more details of why the method calls are highlighted, and what you can do to avoid them. You can get to this documentation straight from Rider, like with many other inspections, with the “Why is Rider suggesting this?” Alt+Enter menu item.

Totally and completely agree with everything you've said, but the fact that Rider - a 3rd party IDE - has to ensure all these things rather than them being baked into Unity is part of the problem.

But Unity isn't an IDE, it's a game engine. Totally different things. Better for Unity to spend their time and energy on the game engine and editor, not making yet another half-assed IDE. Developing an entire IDE simply isn't in their wheelhouse. While it's a lot easier for somebody like Rider who already has a full blown C# IDE to support Unity.

The thing is, avoiding usage of certain functions - like Find, Invoke, SendMessage, etc - does not have to be done at the IDE level. In fact, it shouldn't be, and the fact that Rider has to do these things is kind of a kludge already. These methods should be marked obsolete - or at the very least, they should have docstrings saying not to use them. Observe how the docs for SendMessage don't even discourage its use, for example: https://docs.unity3d.com/ScriptReference/GameObject.SendMess...

Again, Unity isn't an IDE.

The Unity editor gives you compiler errors and warnings in its console window. Why shouldn’t it give you these warnings as well?

The Unity editor also has lots of features that IDE’s have already, including a profiler, ability to inspect the world hierarchy, inspectors for components on that hierarchy, and ability to pause and restart execution.

How about a code editor? All IDEs have code editors, you know. Unity doesn't. Because, again, it's not an IDE.

Unity is a game engine first, the quality of their product will suffer if they have to teach all their user to program properly.

I can't understand how this is the case. Unity is a game engine which keeps users mostly by instilling goodwill that it's a productive environment and is saving them time over using another engine or homebrewing one. It would therefore seem to be in its best interest to prevent them from creating bugs where possible.

That's true, but I've always thought that removing components at runtime is such a rare thing to do, and the cost of allowing it on an engine level - inability to statically verify components - is such a high price to pay that the tradeoff just doesn't make sense.

If I was czar of Unity (ha!) I would never have allowed AddComponent and RemoveComponent to be a thing - I would have required the user to add all of the components they expect to need at edit time instead. The dynamism that Unity currently affords rarely improves my game, but it does lead to a lot of bugs. If users really want to turn components on and off, they could have an enabled flag.

Being able to add / remove components then query based on component sets an entity has is an important part of ECS data driven design, which Unity is trying to move to with eg. DOTS. Just leads to less branching etc. once your data is prepared. I'd rather just have my code express expectations upfront then query the entities that match, vs. needing to handle a combinatorial explosion of if/else based on existence checks.

Well so much for dynamic and procedural and data driven content, under your reign as Unity Czar. People use Unity for a lot more than Flappy Bird clones, you know.

Components do have an enabled flag.

https://docs.unity3d.com/ScriptReference/Behaviour-enabled.h...

Well, I would certainly hope that as my reign as Unity Czar would include guidelines for storing procedural content somewhere other than in Components :)

I mean, if you're adding a new component to a GameObject for every room in your dungeon or something, you're doing something very wrong. At least in my opinion!