Feature Request Additional suffix to repeated methods

Well, everybody (or mostly) knows: put loop in repeated methods like Update() or FixedUpdate() is probably bad idea. But its not obvious for many other methods, like OnDrawGizmos().
At my scene on Editor I draw many lines (from 3 to 5000+) and lately I realized one thing - I do it on loop. Sic!

So, my proposal is: add understandable suffix (or maybe prefix) to methods which calls over and over, and when programmer write code in this method, it will be a some sort of warning: "don't write loops or loop methods here please, better work with cached data".
In API and Manual we can make some warning, like: "Avoid using loops and loops methods in *_Repeated()", and add links to articles with valuable information about Events, Observable pattern, etc.

I believe it is slightly helps to anyone who write code in one or another way. You can easily forget or even don't know this tiny thing and use loops in place, which recalculate your data hundreds time in a second without actual change.

 

The main loop methods have "Update" in their name, and any "OnDraw" or "OnGUI" is also a commonly understood naming convention that this happens every frame.

Besides, any IDE with good Unity support (hint: not VS) will show you hints like "frequently called" above such methods.

Given how much friction this would cause just to make it minimally easier for beginners, it's just not worth considering. Especially since you can cause performance issues within any event method, or if you call some other method from Update() it also starts not being obvious again.

 

This isn't really a decent rule of thumb anyway. Lots of things that happen every frame require looping over some finite set of things.

 

As others stated already, this is for the most part a beginner exclusive problem, and only so, if said beginner puts code into a function without properly understanding what it does. The solution clearly cannot be to rename the entire API. Said beginners simply need to look up the stuff they are working with. You wouldnt want someone to just get in a car and drive without having any knowledge about what any of the things in reach do either.

Nothing particularly speaks against using loops in those methods either, as Praetor said. That's just a way too specific thing to warn about - outside maybe a beginners introduction to Unity. People do a lot of things that are bad'ish. Like putting a ton of unnecessary stuff into FixedUpdate. But you cant warn everybody about every little eventuality. At some point you just have to assume that the people have some background knowledge about the API they use. Or that they read up the documentation when they use something new. Which incidentally is one of the best things about Unity imho - the documentation is fantastic for most things.

Making these mistakes is not the end of the world either. As a general rule of thumb.. if you dont run into an actual performance problem you are fine. And if you do, the profiler will quickly help you to figure out what you did wrong.

 

Also the last thing Unity is ever going to do is rename any of their 'magic methods'.

 

They are literally more likely to rename me and change my avatar. In the forum as well.

 

You say it like: "the beginners problems is their own problems, just don't be a beginner, lol". Unity have bad reputation because those "beginners" make lot of buggy games while "not beginners" still writing they project in the right way. Lot of youtube videos shows awful scripting (and some UnityLearn too...) but beginner consider it as right way to do things.
Point is: "beginners" must know where they are bad, and work on it.
Even when we go to API, then to MonoBehavior, then Update - there is no warning at all. So "beg-inner" stays in beginner-state because it is fine.

Event system is needed for avoid use Update() at all. Or mostly. Again, this is "beginner problem", yes, but it is still a problem, and "just be better" is not a right solution.

I think you heard about LINQ, right? Place LINQ in Update() and you'll see magic! (pls don't)
Not every loop in Update() is evil, of course. But people must know about difference between check 15-30 booleans in Update(), and making array from calculating 10000 variables every frame.

Well, I'm actually not saying "Rename your methods right now!". It SURE will be a problem for everyone. But, it is just basement idea. I believe there is smart guys works on Unity, they invent something better rather than "IDE support", and it will be great for everyone. Not only for people who knows a lot, and purchase cool IDE stuff.
(How about warning comment which is placed in code when you do snippet\template, for start?)

 

Unity puts a lot of effort into the core engine being as backwards compatible as far back as possible. There's a reason why these properties are still in the Component class despite being deprecated long ago and no longer visible in an IDE either:

Spoiler

Changing the name of the magic methods is like... the most breaking change they could ever make in the history of Unity. It's not about IDE support either; their names aren't superficial. Unity is in fact looking for a method called Awake, Update, etc, in the c# objects its handling. The way it handles this is very, very optimised but having to check for more than one potential magic method is overhead that doesn't need to be added.

You say its a change for beginners, but beginners (like myself) will learn and understand how to do things better over time.

 

That is not what i said at all. But the information is out there. As i said, Unitys documentation is pretty strong. You have a full description of.. well.. basically anything? Interfaces, constructors, method signatures, parameter descriptions, examples. Not to mention useful diagrams, like this one: https://docs.unity3d.com/Manual/ExecutionOrder.html

Everybody has to learn things initially. Being a beginner is normal. There is nothing wrong with that either. But you cannot expect people to rename their entire API - which will cause literally every project in existance to break - simply for your convenience. Simply because you miss the things that are well documented.

The only sorta negative reputation of Unity im aware of is that it's inefficient, which is likely due to the core of the engine being single threaded. I have not once heard of anybody having the problems you describe. I dont know how the people who use the engine would serve to give it a bad reputation either. The kind of beginner you are describing would write bad code in any other engine as well. If the people who make youtube videos write bad code, then they are bad coders in general which has nothing to do with Unity either. And i dont think all bad coders would just magically flock to Unity for some reason.

There is plenty of fantastic tutorials. There is the fantastic documentation. There is so much information out there. Yet you act like beginners have no way to know where they are bad. Here, the documentation of Update: https://docs.unity3d.com/ScriptReference/MonoBehaviour.Update.html
It's short sure. But the warning you are looking for is there. "Update is called every frame". I dont want to sound rude, but this is literally what you were asking for, right? You wont find a warning telling you not to put loops into Update, because that would be a ridiculous and quite frankly silly statement that did more harm than good. Loops are not always heavy loads, and not all heavy loads are loops.

If with all this documentation, most of which being a prime examble of good documentation, the beginner "stays in a beginner-state" then that's done deliberately, since he expects his issues to resolve themselves without putting in any effort whatsoever.
Spoonfeeding is not a thing. Not in Unity and not in other engines. Usually, not in life in general.

Yes. Which comes with experience. Most people wont even attempt to do something like that. The majority of which, because they dont need it. It's a cornercase problem. Of the remaining few.. id argue that a good chunk knows intuitively that this is a bad idea. But even if not, they will quickly realise so and can then easily fix it aswell.
Last but certainly not least: this is simply not a Unity related problem. Technically speaking it's not even a game development specific problem. So why would any (and with that every!) specific tool need to teach this to their users. You need to learn this once, and then you know it for all other areas of programming.

Beginners make a cube move. If you are ready to manage tens of thousands of variables, you are ready to learn that you should not do that every frame. And learning that is indeed your responsibility, as it is your usecase.