koobas.hobune.stream
Too subjective and argumentative
Why does Unity3D encourage use of public variables instead of setters/getters?
While there are other examples, the most notable case is that only public variables are exposed to the inspector window.
By encouraging use of public variables, this also encourages new programmers to avoid the use of properties and setters/getters, which are established to be much better practice than using public variables for the same task.
You can write a custom inspector to get the proper behavior, but I am wondering if I am missing something with understanding why Unity didn't provide this out of the box, yet they provided inspectors which encourage the bad practice.
Background:
It's my understanding that public variables in Unity are strictly meant for debugging / prototyping. It's a lot more convenient to select your main character and change the "speed" field than it is to open up your IDE and find the exact spot for the code and change the value that way. Granted it doesn't take that much longer, but if you have to test out 100 different values, public serialization saves a few $$anonymous$$utes.
Personally, whenever I do prototyping and debugging, I use [SerializeField] private variables just so nothing extra would plug up my intellisense and so that I can keep some of my fields semi-immutable. Even for a lot of non-debugging issues, I use [SerializeField] where convenient.
Lastly, it's a matter of personal preference, and it probably isn't intended to deter new programmers from properties. The current state of serialization via Public variables is fine and great. However if new programmers spam public fields then they'll learn the hard way that it makes coding 10x harder. At that, if a new programmer jumps into Unity with absolutely 0 coding knowledge expecting to make something great, public fields will be the least of their worries.
I just read the majority of :
http://c2.com/cgi/wiki?GlobalVariablesAreBad
Now I'm a self taught programmer with only a little over a year of experience, so take this with a grain of salt haha.
But I really think some people severely over think certain details like this (I've seen many similar posts with people really putting a lot of effort to complain about C# or other program$$anonymous$$g aspects in Unity).
I think Unity is just not designed in a way that will seem "scientifically correct" to a lot of heavily schooled computer science majors. Or in other words some of what you learned while designing other programs and studying computer science in general is not necessary with Unity and may even be counter productive.
Unity is designed in a way that it's really easy to work with. It's supposed to do the hard work for you and let you be creative with your game design.
I read a lot of that link and to me it just sounded like "Beware of public variables or public static variables they are bad if you don't use them correctly!" Well of course they are bad if used incorrectly! But both public variables and public static variables are incredibly useful and easy to work with in Unity and I don't really see any downsides to doing so in my experience.
@RyanZimmerman87 The issue isn't just that using public variables is dangerous. It's also pretty limiting. Per my response to the below answer, you can't do things like input validation/processing or locking.
You are probably right there are a LOT more potential problems than what I'm thinking about since I'm kinda a noobie programmer still.
But I would have to imagine you could do input validation/processing or locking just by adding unique logic to your scripts to make sure things are correct or working as expected?
For example when you get new input that overwrites the old one you could temporarily store the old one and then after processing replace the new one if it's not correct? $$anonymous$$aybe I'm just not understanding a lot of these more complex program$$anonymous$$g terms or what you can't do with public variables.
@Wisteso I want to ask as an aside, what it the point of using a public property where both get and set are are not given any extra logic controlling the reading and writing of a var? This is $$anonymous$$Y PERSONAL OPINION haha, but I think only use a property when you need to protect how it is read or written to. Unity actually has a tutorial on properties and does a good job of explaining a useful use case.
It is not compulsory to use public to expose variable in inspector. There is an attribute [SerializeField] which is used to expose private variables to inspector.
This definitely helps to keep the API clean, but the other primary issue is that there's no ability to perform input validation, pre/post-processing, or apply locking.
You can implement getters and setters using the private variables as backing data if you wish, where design-time validation would done via custom inspectors. You can even wire the inspector to actually get/set the properties for DRY code.
