Fields, Properties and Serialization. - SuperiorJacob/ComputerGraphicsShaders GitHub Wiki
This wiki page contains information on how to properly layout fields, properties, serialization and some useful tips of usage.
Table of Contents
Naming Conventions
Heres the basics to always remember:
- Always use camelCase for fields.
- Always use PascalCase for properties.
- All private variables that have a property assigning to it, must be underscored.This also applies to editor exposed variables like public/serialized. Example:
private float _expensiveCalculation; public ExpensiveCalcuation { get => return _expensiveCalculation; set => _expensiveCalculation = value; }; - Your variable names must have two words atleast, example instead of speed, in which is a float thats used to manipulate movement, you'd therefore make it movementSpeed, this also allows the reader to understand what the variable does aswell as find it much easier.
- Booleans are usually is doing or is not doing, so an example is: isJumping isRunning, isShoooting etc.
Fields
The field, a pesky variable that without being done properly can lead to some very annoying circumstances later on.
Private vs Public
Now, obviously you know the answer, if you want a variable to be accessed by another class you just make it private and make a get setter for it, but heres the problem, when are you meant to make it public, serialized, or use a get setter? Well in unity this is a very big question that doesnt exactly get explained thoroughly.
Public/Editor
There are three types of Public variable usage, being lazy - editor - accessability.
Obviously we want to avoid the lazy usage but in some cases being lazy is perfectly fine and fits into the standard, for example if we have a variable that is constantly changing and constantly being read, with zero calculations its literally just a variable then by all means make it public and go ham (Examples of this include but not limited to: Arrays, Structs, Classes etc).
This sadly becomes terrible when its a variable thats got some form of calculation, checker, or is a read only value, ontop of that it will be exposed to the editor unless you add a [HideInInspector] before it, but we still want to avoid any uneccesary public data, so thats where Properties come in.
Now, if you want a value in the inspector but also accessable by everything then yes, make it public, like by all means this is perfect practice and is great accessability.
Now if you have a private variable but wish to expose it to the editor you can use [SerializeField].
Layout and Organisation
When laying out your code from the top of the class to the bottom, this is my way of doing it and probably the nicest:
- Static
- Editor (Publics, Serializes)
- Privated
- Properties
You also want to organise things and place them together if they have the same goal and if they dont or you have alot of the same type organise them like this:
- Variables
- Structs/Enums (Vectors, Enums, Data)
- Classes
Remember you can also use the [Space()] attribute to seperate variable types to make it neat. Also remember to use the [Tooltip(string)] attribute for easy understanding of what the public variables do.
You can also use the [Header(string)] attribute to declare a header for more readability in the editor.
Now, lets say you have several game objects needed, then make a list or array instead of making a bunch of variables. Or if you have a bunch of data like information for movement or information for many things that are in the generalized category of something like Movement, Shooting, Rigging etc, you can make a public struct in your class, [System.Serialize] it, and this allows you to have a category in the editor and have all your data nicely stored in one block instead of many!
Also structs are useful if you want a bunch of objects with different names but also dont want to clog your code.
But don't forget, if your going to have a heap of data, and multiple objects who also use said data or have their own, look into ScriptableObjects instead of clumping all of your memory onto this component (Remember, ScriptableObjects should also follow the same coding convention).
Layout Code Example
csharp
Properties
A property is a way of handling the setting and getting of any field. This is very handy and useful for calculations without actually making multiple methods instead you can have everything defined in a get setter. Sadly because of how unknown a property can be on how it handles setting and getting, you cannot use these in the inspector. Thats why when you want inspector values just make them public fields, and handle properties as if another class was accessing it.
Serialization
You can pretty much serialize, what this does is expose any variable to the inspector and it will try its hardest to understand it. This allows for making private or protected variables editable by the inspector. To do this just right [Serialize] before any private variable and nothing can access it but the inspector can edit it. Good for object definitions.
Another thing you can do is use [System.Serializable] before a struct or class and all of a sudden it will display in the inspector.
How to change variable names without losing the current editor customized version
Before changing the variable names, add a using UnityEngine.Serialization; to the top of the file. Dont worry, well delete this shortly.
Now behind every value your about to rename put this before the entire line [FormerlySerializedAs("currentvaluename")] and do not save until you have written the value name. Then right click the value and click rename, now rename that value and it should update! Do not use replace all otherwise youll lose your stuff you must individual rename or use visual studios nifty rename tool. Now save the file and watch the new variable not delete its previous value. Useful for data in anything.
Now that you did all that, you can delete the using UnityEngine.Serialization and every FormerlySerializedAs and boom your all done your values have a new name and kept the old values!