I’m watching a tutorial from another website and they use SerializeField rather than making the variables public like in the Unity tutorials, to make the variable editable in the Unity editor
thanks!
3 Likes
SerializeField makes a field display in the Inspector and causes it to be saved.
public makes a field display in the Inspector and causes it to be saved, as well as letting the field be publicly accessed by other scripts.
I personally think using SerializeField and using a private field is better, since it prevents external access to the variable.
13 Likes
Serialisable fields show up in the inspector. By default public fields are serialisable. As are any fields you mark with SerialiseField.
It generally makes sense to treat showing up in the inspector and accessibility seperately.
Here are the four different possible combinations
- public - Show up in inspector and accessible by other scripts
- [SerialiseField] private - Show up in inspector, not accessible by other scripts
- [HideInInspector] public - Doesn’t show in inspector, accessible by other scripts
- private - Doesn’t show in inspector, not accessible by other scripts
86 Likes
ok i get it! thanks to both of you for your quick and clear answers!
@Kiwasi - i hadn’t seen that HideInInspector before, that’s interesting
1 Like
Should probably also mention protected access modifier.
The type or member can be accessed only by code in the same class or struct, or in a class that is derived from that class.
2 Likes
you’ll love this one when you start doing editor scripting 
3 Likes
Just as a notifier, in the Unity 5 sample projects you’ll also see that the guys from unity use [SerializeField] private. The biggest reason to use that is encapsulation, one of the main pillars of Object Oriented Programming (OOP) in C#. Encapsulation is the process of hiding implementation from external classes, which you should always strife to do.
More about encapsulation and some samples can be found here: Lesson 19: Encapsulation - C# Station
Personally I’d like ‘[HideInInspector, SerializeField] private’ more 
1 Like
Another useful attribute is [ReadOnly]
It makes the variable show up in the inspector, but read-only so it can’t be modified in the inspector.
"[ReadOnly] [SerializeField] private "
You have to create your own editor script:
7 Likes
thank You so much buddy.
I’ve never really understood why I wouldn’t just make the field public. Like there’s no memory overhead or anything right? And its not like another component is going to reach out and try to modify a public variable unless you specifically code it to do that.
I guess it is more for a kind of peace of mind in the mind of the coder who prefers to feel things are sealed in? For me I find that making fields public usually opens up the possibility for more interoperation and emergent potential. And I only use private if I really want to hide the variable in the inspector.
1 Like
This is the exact opposite of what people mean when they talk about good coding practices. You absolutely don’t want this kind of tightly coupled interoperability. There shouldn’t be an enemy that just says “player.health -= 10”, which is what making variables public promotes. What you call potential, I would call a debugging nightmare. Just imagine dozens of objects all talking with each other by accessing public variables, and now you notice one value doesn’t seem to be correct. Good luck finding the cause for that.
I’d still argue it doesn’t really matter when you’re working on a project alone. But most of the time games aren’t developed solo. Imagine you making all of the variables public, now some other programmer comes along, types “player.”, sees that health is public and just changes it, because that’s what they need right now. This is the main reason why you don’t want to make everything public. Scripts shouldn’t work by constantly changing each other’s values. If you have ever worked with another person on a project with a lot of classes, you’ll immediately understand why things need to be isolated as much as possible.
8 Likes
Perhaps you’ll remember that detail today. How about a month from now? How about a year from now? How about if you give this project to a friend so he can try it out and get started?
How about if your project is so successful that you make a public package out of it?
When you write code you ideally want it to be self-documenting. Even if it’s only for you, if you pick this code up in the future, you want its public surface to tell you things.
If you make something public that should NOT be public, you are in effect saying “This is just like every other public thing in here, go nuts with it!”
Instead, best coding practices say to make everything private that CAN be private, and only expose the surface you intend other code to manipulate.
Am I religious about doing this? Nope, I go lazy sometimes too. But at least I try to keep the easy stuff private. And in general, I would never manipulate a public field unless it was clearly intended for that external use, either by comment or by name. It’s always better to make a method called SetFoobar() than to just have a public bool Foobar; and setting it to true.
4 Likes
this has to be the best description of why to use serialized private I’ve hear you make a lot of great points
Hi I know this is old, but can you please explain what you mean by “External access to a variable”
“External access” would be to use that field from anywhere other than the class that declares it.
Or if one of your colleagues does so. Without fully understanding what your code does.
Leading to a bug that takes you 3 weeks to find.
Trust me… I’ve been there.
Every script should have this IMO.
Then just start throwing exceptions every Update whenever it is true.
@ please implement this in the engine. You can also call it “FUBAR” if you want.
This is the most clear and concise explanation I have ever read our heard about this. I had a general understanding but because of how it was always explained I kept forgetting or mixing it up this makes it simple and understandable.