[SerializeField] vs What everyone shows you in Youtube Tutorials

Unity Courses Talk
, ,
#1

Okay, so this may well get covered later - and I expect there is a technical explanation that is yet to become clear in the context of the course, but in parallel to my studies here, when I look at Youtube tutorials on Unity - I’ve never seen anyone talk about using [SerializeField] for getting a setting to be available in the inspector. I believe they just declare a Public variable and it does what appears to be the same thing.

Is this bad/lazy practice, or is that something you learn how to manipulate better over time once you understand more about Public uses in general.

I did find one tutorial that advocated the SerialzeField method above the Public variable method because it limits what can access the variable to just the script where it originates. Does this mean that if I see a Youtuber utilizing the public variable method - and they are not intending to reference that variable from elsewhere, they’re committing some kind of coding sin? :slight_smile: And if so, what are the inherent risks? That you could accidentally call it inadvertently from another script without realizing and generating odd behaviors, or errors that are hard to debug?

Quick Update Edit;

The notes for this lecture give a link to the use of Range on the Unity documentation videos. That video exclusively gives the technique in the context of using a public variable! I can’t help thinking this is just a bit confusing for a newbie like myself, giving an explanation of how something works, in the context of something we haven’t yet covered!

1 Like
#2

https://docs.unity3d.com/ScriptReference/SerializeField.html

In brief, using the [Serialize Field] attribute tells Unity to make a private* variable visible in the Inspector. It gives you the functionality of seeing it in the inspector, while still “protecting” it from outside classes.

*Yes, you can also use it with a public variable, but why? As you note, anything set public will already appear in the Inspector.

Regarding the YouTube media you are watching… are most of the videos from seasoned vets? or from mid-tier programmers making videos to reinforce what they are trying to learn? I wouldn’t really know, but I would like to think the vets would be more inclined to use Serialize Field whenever appropriate, whereas if the videos are from less experienced developers it’s possible they are all just copying each-other’s bad habits.

How big a sin is it? Another good question I can’t answer for you, because I’m a mere hobbyist, not a guru. It’s a good general policy to escalate privilege or scope only as needed. As such, it’s at the least a minor sin to use a public declaration over the use of serialize field when, as you note, there is no call for the extra privileges. I suppose the grey line is dynamic; for small personal projects – who cares? but for something industrial strength, lean on your Best Practices.

3 Likes
#3

Good questions!

You will often find tutorials/examples where the fields are set as public often to avoid the discussion of access modifiers, this can be a little bit easier on those new to programming and can be a topic introduced later, as the material progresses. In the same sense, you often see examples without any access modifiers, but with no explanation that, by default, private is applied in C#.

It’s a good general policy to escalate privilege or scope only as needed.

:+1:

Absolutely agree with Jack on this. As a developer, even when you’ve gained years of experience, it can be tempting to start thinking ahead, creeping the scope and saying things like, “I might need this later”. What often happens is then those awesome features that you thought were going to get applied don’t, perhaps your project runs out of time, finances, or other projects become the priority. You leave those fields exposes as public. Two years later when the project is next opened, no one has any recollection of why they were exposed, everyone is too afraid to change anything because they don’t want to break it, so they get left again.

Apply what you need, when you need it, remind yourself frequently through a K.I.S.S :slight_smile:

With regards to the link to the Unity tutorial, in that example they are specifically covering the use of the [Range] attribute, it’s used on the movementFactor variable I believe. In the Unity tutorial, they apply that to a public variable, what you don’t see/have explained, is that the speed variable itself is most likely set to public for a good reason, e.g. accessed by other code.

You can stack the attributes, so, if you wanted to you could have a serialized field which also uses the range attribute.

See also;

2 Likes
#4

Thanks Rob and Jack

Very helpful and insightful.

To give some background - I’ve periodically been going back to Youtube tutorials - mostly because that’s where my first exposure to Unity and C# began. I honestly couldn’t fathom what any of it meant early on, then as I’ve been working through this course, I’ve been going back to Youtube tutorials to see if any of it makes more sense with the gradual knowledge and experience I’m building up.

I’m pleased to say it is helping - I can at least grasp the principles of what they’re doing most of the time, but this point with the public variables was confusing because a lot of basic tutorials I’ve seen, the only explanation given was ‘I want this value in the inspector, stick it in a public variable, there it is - isn’t that amazing!’ Maybe it’s just the way they learnt to code - maybe they’re repeating how they learnt it. For a tiny project, you could make the argument for saying whats the harm, it works, right? But I take the point that as a project scales up, it could become hugely impractical. It sounds much more sensible and practical to expand the scope only as it’s required. I mean, if you suddenly have a variable that actually does need to be accessed from elsewhere - it’s just a minor thing to go in and change to public, right? That sounds logical.

Thanks for making that a lot clearer :slight_smile:

Jim

1 Like

Privacy & Terms