I'm cleaning code up.. What is the patterned terminology for denoting types of functions?

Scripting
1

I’m cleaning up my scripts. I’m a bit of a novice.

Wondering how people differentiate types of functions in their head or in their work.

For example

using ~~~~
using ~~~~

namespace Core
{

    public class OrganizedFile : Monobehavior
    {

        //Variables
        [SerializeField] private FieldClass variableName;
        private FieldClass variableName;
        private FieldClass variableName;

        //Game Functions


        //Initialization Functions
        void Awake()
        void Start ()
        void OnEnable()

        //Update Functions
        void Update()
        void FixedUpdate()

        //Collision&Trigger Functions
        void OnTriggerEnter2D()

    }

}
2

if ctrl+F search also picks up keywords in comments in whatever IDE you use, it may be worthwhile to put short notes about when, where, and why functions are used. This is not so much for explanation but rather for search. So in the future when you cant remember exact function name, so long as you can remember a few broadly related keywords, search should pull it up before your brain has to go so deep. Just saves a lot of effort.

The idea is that you never have to scroll through code with eyeballs. just remember broad categories and computer gets your there without having to lose focus on what you are actually trying to do, rather than remember where stuff is.

2 Likes
3

You can use #region and #endregion to organise code into collapsable groups, if that helps.

My usuals, for example:

public class SomeMonobehaviour : MonoBehaviour
{
    #region Inspector Fields
   
    #endregion
   
    #region Internal Members
   
    #endregion
   
    #region Properties
   
    #endregion
   
    #region Unity Callbacks
   
    #endregion
}

Plain C# classes usually have one for constructors as well, and after this usual lot there’s categories for the various methods a class usually has.

2 Likes
4

Love this and will start incorporating in my next session. Thank you!

5

Good idea to routinely refactor. And maybe get in the habit of calling those “variables” properties and the “functions” methods. It is C# may as well use the terminology. Regions is a good idea.

1 Like
6

This is great. I’ll also start using this from now on.

Novice question, but internal members are just variables that are needed to run code within that script, yes?

And are you grouping Unity Callbacks for things like coroutines?

Do you not personally wrap initialization functions and the update function?

7

Very true. And good idea!

Isn’t a property a bit different than variable though as it involves a private field that allows read and writing through a get and setter?
Maybe I’ll name the variable section Members or Fields then to be more accurate if that’s correct then hm. It’s been a while since I’ve done a C# course so I wouldn’t be surprised if I’m wrong though lol

1 Like
8

Unity Callbacks is for Awake, Start, OnEnable, Update, etc. Any of the Unity magic methods, effectively. It could perhaps be called ‘Unity Messages’.

Internal members are private/protected fields that aren’t serialised for use in the inspector.

They’re not hard and fast categories, of course. Some scripts won’t have some, some scripts will have different ones. But it’s another tool that can be used to organise code.

1 Like
9

Awesome. Thanks for sharing :smile:

10

Those variables aren’t properties, though. Properties are a type of function call which, by convention,tend to wrap a variable. I’m not seeing any in that example.

The functions in there are indeed (also) methods, but both are correct.

2 Likes
11

I’ve found Microsoft’s guides offer a good starting point, for naming and code conventions.
Especially useful is to name properties and classes as nouns, whilst methods are verbs, enums are singular not plural etc.

Framework Design Guidelines | Microsoft Learn
General Naming Conventions - Framework Design Guidelines | Microsoft Learn
NET documentation C# Coding Conventions - C# | Microsoft Learn

Its also good practice to use a ‘.editorconfig’ to ensure your code is consistent
NET code style rule options - .NET | Microsoft Learn

3 Likes
12

As others have pointed out there are “fields” sometimes called “backing fields” when a property provides access to a private field. I refer to them as properties if I’m not discussing syntax minutiae with someone. They are very considerably different than variables.

I would suggest you experiment a bit rather than decide on exactly the sections and section names at the outset. I’m a big fan of evolution and letting your solution be guided by your needs and what makes the most sense to you. Except (and it is big exception) if you opt for some outlandish, nobody-does-it-this-way standard. Eventually you will share code with others and “way out of whack” (it’s a technical term) :slight_smile: just makes things harder for everyone.

Consider “guides” as a guide not a gospel :slight_smile:

1 Like
13

I agree with Spiney, #region is one of the best things ever created! As in some of my ‘jumbo’ classes can have over 300 variables, so cutting each of those into their own regions is a life saver. For example my AI model bone modifier project can easily cut all variables associated with right arm, separated from left arm.

Not just variables, but everything else(functions/methods) as you can even group Unity methods(Awake, Start, Update, OnEnable) into one region, so scrolling up and down the page, doesn’t make your mouse scroll wheel start playing the fast and the furious soundtrack, lol…

1 Like
14

Is this a case where nested classes might help?

15

I had tried to make classes to be child specific, like “ArmRHandler.cs” and so forth for other limbs, but I found myself re-typing a lot of the same things, so having it all in one class, not only made it easier, but gave my fingers a break! lol..

But I can agree, in some cases it is better to separate things, and have a class for each.

And in other cases, it’s better to just have it all in one place. Really depends case by case.

16

Hmm I wasn’t thinking of separate classes per behavior necessarily more of a case for grouping. Going to be tricky to explain but I have a system I am particularly happy with using structs so I can “reuse” property and method names without a conflict. So I don’t name something rightArmPosition but rather something like rightArm.position.

For example… a bunch of things could have “First, Previous, Next, Last” type components. But I can uniquely address the Video set from the class that uses the struct with Video.FirstButton and Video.Title for instance.
.

 public VideoStruct Video { get; private set; }
17

Well I just mean what would’ve cut down the jumbo class(as it were), fore-going the need for many #regions. To which I found regions being better.

If you’re truly interested in the fore-mentioned case, then pop a gander at just a few of the functions I gave in this post:

But be warned, it might cause your head to explode, lol, so be ready to back out of it at a moment’s notice. :face_with_spiral_eyes:

18

Oof. That sounds like it needs a solid refactor. At the very least break things down into smaller structs/classes to avoid repetition. I’ve never had a class blow out to be that big.

4 Likes
19

Well that’s what I mean, trying to break it up cause way more typing than if it was just in one spot locally. For example just key bone rotations was:

   #region Main Variables
    public GameObject maya_obj;
    float mayaSize;
    [Range(0.3f, 0.5f)]
    public float mayaSizeNew;

    public GameObject root_bone;
    float bodyHeight;
    float bodyHeightMax = 0f;
    float bodyHeightMin = -0.046f;
    [Range(-0.046f, 0f)]
    public float bodyHeightNew;
    float bodyForward;
    float bodyForwardMax = 0f;
    float bodyForwardMin = -0.02f;
    [Range(-0.02f, 0f)]
    public float bodyForwardNew;

    public GameObject hip_bone;
    float hipRot_X;
    [Range(-100f, 40f)]
    public float hipRot_Xnew;

    public GameObject chest_bone;
    float chestRot_X;
    [Range(-40f, 60f)]
    public float chestRot_Xnew;
    #endregion

Not to mention each other specific areas of the model as well:

#region Right Arm
    public GameObject rightArm_bone;
    Vector3 rightArmRot;
    [Range(-100, 75)]
    public float rightArmRotX;
    [Range(-60, 60)]
    public float rightArmRotY;
    [Range(-160, 66)]
    public float rightArmRotZ;

    public GameObject rightForearm_bone;
    Vector3 rightForearmRot;
    [Range(0, 1)]
    public float rightForearmRotX;
    [Range(-80, 60)]
    public float rightForearmRotY;
    [Range(-150, 0)]
    public float rightForearmRotZ;

    public GameObject rightHand_bone;
    Vector3 rightHandRot;
    [Range(-80, 80)]
    public float rightHandRotX;
    [Range(-20, 20)] // may actually be more, depends on forearm
    public float rightHandRotY;
    [Range(-40, 60)]
    public float rightHandRotZ;
    #endregion

As the class was a model “edit”, so could be used in the Inspector during edit mode(Slider values). Still functioned within play mode, but it was more about setting angles and rotations per what movement.

But it was one of my AI projects, where the model used real determining factors, on how to think and move for itself. even so much as the feet using load bearing points, to physically move(instead of animation just “looking like” it’s moving)…

It was a nightmare, I will admit, but was fun until it burnt me out. :slight_smile:

20

Yeah that’s a bit disconcerting :slight_smile: The issue with these types of trade-offs isn’t necessarily that you might get confused and need a lot of time to understand, modify and retest it but rather that this (probably) wouldn’t pass a code review if you aren’t the person in charge :slight_smile:

Quick off-the-cuff remarks follow but your RotateLegR, RotateLegL and 6 other “rotate” methods have only a single difference the property to assign the result to. It could return that value and you reduce 8 methods to 1.