Methods -- Where to define them

So as this noob works through various beginner tutorials, one thing I’ve come to learn by trial and error is that the order you call methods in the start function matters. How many hours I’ve wasted scouring through line after line of code looking for small typos…

But one thing that I am wondering about: I don’t seem to see any logic or pattern to where in any given script methods are usually defined. Sometimes they are in the update function, then called in Start. Sometimes they are defined just in the class but not inside update.

Is there any logic/best practice on where to initially define our methods? I understand that certain methods should be called in certain places dependent on the function, but is there any good reason to be careful about where we define them?

You don’t define methods within other methods. Unless you mean you want to call a method? Or do you mean what method you should put code in?

Absolutely. Where you call methods and when are very important.

So, say you have a generic method called “UpdateWheel(float steering, float power)” This method updates a wheel and wheel collider so that your car can move. If you call it in Start, it will set the initial steering and power of the wheel. If you call it in the update, it will update the wheel each draw cycle. If you call it during the FixedUpdate, it will update the wheel during each physics update.

That being said, why would you call it during Start, or why Update or even FixedUpdate? This depends on the game and how often you need to have the method done.

So lets look at another method “CreateRigidBody()” This method initializes a rigid body (if it does not exist) Would you call it during the Start, Update or FixedUpdate? The logic could say, the fixed update needs a RigidBody so that it can move the object in physics, however, that RigidBody really should not be created EVERY physics update, it really needs to be created once. Same with the Update. It should not be created every scene draw. The Start, however, only happens once, and it happens before any Update or FixedUpdate ever happens. So logic says, it should go there.

So let’s say I have decided that I need the UpdateWheel() method, and I know where I should call it. But does it matter where I initially create the method? Can I just write it out anywhere in the class? Or just in any script so long as it is public? Could I, theoretically, create a standalone script attached to an empty game object that is just nothing but public methods to be called in other scripts? I think the answer is yes, but I guess my main point is, for optimization purpose, does it matter where I initially write out the methods?

ah, where in the class. No, it does not matter where in the class. Public or Private can matter.

Public methods/variables are Accessible from outside of the class
Private methods/variables are not accessible from outside of the class

Static methods are methods/variables that can be accessed without an object. (public and private matter here too)

So, Public UpdateWheel() can be called as such:

wheel.UpdateWheel() - or - UpdateWheel() (from within the class)

However, Private UpdateWheel() can only be called:

UpdateWheel() (from within the class)

Public Static UpdateWheel() can be called like so:

Wheel.UpdateWheel()

However, this does not have an object, so it doesn’t know which wheel should be updated.
You generally use Static methods to create things:

var wheel = Wheel.NewWheel(mesh, position) // this is a public static method on the wheel class
// you then call this:
wheel.UpdateWheel(); // this is a public method on the wheel class

Where you put a method in a class doesn’t matter, however most will try to group methods together if they do similar things. Like, a method that adds to a score and one that subtracts may be near each other.

Yes, you could create a script and attach it to a empty game object and simply call methods on it. You could also create a script that doesn’t inherit from monobehavior and doesn’t need to be attached to a gameobject.

Ok, it makes sense now. Thanks guys!