Be the first to post for 'Instructor Hangout 2'!

If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.

One use case for HideInInspector annotations, that I’m using is, when I’m creating child gameobjects within a script from a template at runtime. Since the state of these child objects is dependent on some other object’s concurrent state at runtime (i.e.: content of player’s inventory is dependent on what the player has been doing), they can not be pre-set in the Unity editor. It is therefore pointless to expose fields of scripts controlling these child objects to the editor, yet often one should be able to set some fields of these scripts at corresponding object instance’s creation (and Unity dislikes constructors).
So again, it comes down to either using private fields + public properties, or just public fields. In case there is no logic in the property’s setter and getter there is most probably no added benefit to using a property and one might as well use a public field, since that is less boilerplate. It’s not the OO way, but in my opinion, code readability is better than sticking to each and every guideline like it’s the law.

Privacy & Terms