I see a lot of great tutorials that make a big mistake. They advocate making lots of public fields/variables in Unity scripts. Even some of the best tutorials do this, and it’s BAD! It’s no surprise then, that many beginners make all of their variables public.
Public fields have their place (or they wouldn’t be available), so using public isn’t always wrong. It is just that many Unity developers use public incorrectly, leading to poor programming habits that can make code hard to work with and debug.
tl;dr
Basically, unless your field needs to be accessed from other scripts, keep it private.
Much of the time in Unity tutorials, a field is made public so that its value can be seen and edited in the Inspector window. You don’t need to make a field public for this!
If you want your field to be accessible in the Unity Inspector, you can do the following:
// myField is private, but can be seen and edited in the Inspector[SerializeField] float myField;[SerializeField] makes the field appear in the Inspector, where you can view and change it. But it is still private.
You also have the option of using a ‘setter/getter’ if you want other scripts to be able to read a field’s value while only letting the field’s own script modify it:
// myField is publicly readable, but can only be modified in this script
public float myField { get; private set; }What is Public in C#?
When a field (or a method for that matter) is public, it can be accessed from other scripts. Most fields and methods should be private (only accessible to its own parent script), as this makes code more robust, manageable, and modular. When fields and methods are being called from all over the place, it’s hard to keep track of what each script is doing; it can become a nightmare to debug.
Think about it…if a field is public and you decide to change how it behaves, you must also check that any other script accessing it is reworked to fit the change. If you find that your field value is being set incorrectly or a public method is being called at the wrong time, you will need to figure out exactly where the incorrect code is, which gets harder the more complex your project is.
Using public fields and methods can make things easier because you don’t need to think too hard about how to call methods and access variables. But don’t be lazy! It’s really not hard to avoid public stuff in your code, it just needs a bit of experience and practice.
The rule of thumb to always keep in mind is to restrict access to everything as much as possible.
If your code is well structured, public stuff isn’t going to be needed as much. If you find yourself needing lots of public fields or methods, it’s quite likely your code is poorly structured.
Keeping Privacy
Here’s what I do:
- make every field and method private (this is easy, as it’s the default).
- Use [SerializeField] by default for anything that needs to be in the Inspector.
- Only change things to public when you need to access them from other scripts and after thinking about alternatives that don’t require public access (this becomes easier with experience).
- Regarding the above point, consider a ‘public get, private set’ field if you only need to read the value from another script without modifying it.
Conclusion
Avoid public fields (variables) and methods/functions unless you have a real need for them to be public. Use [SerializeField] to enabled private fields in the Inspector without making them public.
If you want to learn more about the reasons for keeping code private and modular, I recommend picking up a book on C# programming (or even programming in general). It’s one of those topics that doesn’t seem too important to beginners (hey, making a field or method public doesn’t change the way it works, right?), but the more experience you gain, the more important it becomes to make your code higher in quality.