- Home /
Most useful Unity built-in attributes
I love this post from stack overflow (I think it should still be open, because it showed me a lot of little known attributes), and I notice that I don´t use attributes very much in Unity, although they seem very powerful. Which are the most useful ones, or at least the ones that you use more often?
Answer by robhuhn · Dec 11, 2013 at 03:59 PM
A list of all Unity attributes can be found here:
The Attributes I use most are Serializable to display whole objects in the inspector
[System.Serializable]
class MyModel
{
public int Id;
public Color C = Color.white;
}
.
HideInInspector if I have public fields and don't need the accessor
[HideInInspector]
public int MyCounter;
.
And RequireComponent to prevent null pointer exceptions
[RequireComponent(typeof(Rigidbody))]
public class MyClass : MonoBehaviour
{ ...
Answer by CHPedersen · Dec 11, 2013 at 03:19 PM
Great question! Though perhaps better suited for the forum because of the discussion/debate nature of the question and answers which is sure to follow. There is no single answer for this, but the attribute I use most often is [SerializeField], for example:
[SerializeField]
private Transform prefabPrototype;
This attribute causes a field to appear in the inspector where you can manipulate it. I use it because Unity only serializes public variables by default, not private ones. But in object oriented programming, there are lots of cases where it makes no sense to make a variable public, and I refuse to violate that principle just to work with the variable in the editor. [SerializeField] solves that.
This is great, thanks! I was really bothered that I had to make variables public to see them in the editor.
$$anonymous$$aybe it would suit better forums, but this has so much better visibility here! It´s a sin I am willing to commit... and you see, this question already helped one person!
I have been overusing public variables for that reason, but usually go back and make the ones private that I can. What I want to know- is it merely "bad form" to have public variables that are only used locally, or does it actually create memory overhead / reduce performance of the compiled game? I assumed it does, but that's more of a superstitious hunch than anything I've tested or read or have a technical explanation to back up.
$$anonymous$$iloblargh, it is not about the performance or bad style, it is about avoiding accidentally changing an instance's variables when you didn't mean to, thus leading to bugs that can sometimes be hard to track down.
There is no performance overhead in using the public keyword. It's stored in RA$$anonymous$$ (or rarely in a CPU register), just like private variables. The access modifier only ensures, at compile time, that no unauthorized access is done to a field.
Having an object's internal state declared public violates the Object-Oriented Program$$anonymous$$g principle of encapsulating data to objects. What's the point of having objects if anyone who has a reference can mess around with their internals? A rather clumsy analogy: how'd you feel if I came to your house and messed everything up? (The house being an object and its tidynes the internal state.)
Access to objects should be limited to the services an object can provide; just because an object has a field for color, doesn't mean anyone should be able to change it.
Answer by Kiloblargh · Dec 11, 2013 at 08:44 PM
For me it's no contest...
[RPC]
All the others I could do without.
Can you explain? I didn´t quite understand the documentation.
Or @RPC
, for Unityscript. Having multiple NetworkViews with state synchronization is fine for getting a quick demo working, but for a serious multiplayer game project, (especially with more than 2 players, and/or multiple controllable units) it's wasteful, so everything should be done with RPCs ins$$anonymous$$d. The [RPC] attribute before a function just means "This function can be called remotely." They were confusing at first but now one of my favorite built-in Unity features.