An Overview on Variables (C# and Unity)

Just a quick article on the subject of variables (and a couple things I’ve been interested in and thinking about recently with them). As a brief overview, the definition which immediately comes up for a variable in computing is ‘a data item that may take on more than one value during the runtime of a program’. They can be thought of as containers for values which are, as the name suggests, ‘variable’.

Types, Declarations, and Initialisation

Variables can take a wide variety of different types, with some of the fundamental and most common types being int (integers), float (floating point numbers), bool (true or false values), and string (literal text). In order to create and use a variable it needs to be both declared (giving it a type and a name) and initialised (assigning it an initial value).

Declaring it usually takes the form of:

int myInteger;

While initialising it usually takes the form of:

myInteger = 4;

A variable can be declared but not initialised (at least until later), but it must be declared in order to be initialised. As a general rule, try to declare your variables as close to where they’re used as possible. If they don’t need to be declared at the class level, try declaring them within the method where you need to use it. I could be wrong, but I feel like it’s generally good practice to both declare and initialise your variable in the same line where possible:

int myInteger = 4;

Now that we’ve done this, our variable is ready for us to perform operations on it, use it, and assign it a different value (using the ‘assignement operator’/‘=’). It’s hard to overstate how important and how central this is to a lot of we do in programming. There are a few more advanced concepts, such as passing variables into methods by value or by reference, but I’ll leave that for a later date.

Access Modifiers

One of the other things I’d like to touch on are access modifiers. We use these at the class level (essentially, declaring them within our scripts (or classes more specifically)but not within a specific method), and they determine to what extent a given variable can be directly changed or ‘accessed’ by another class/script. It’s generally good practice to specify an access modifier for your class variables, and it’s even better practice to follow a naming convention so we can tell at a glance which access modifier applies to them. The two main types are public and private, but you’ll also occasionally see protected (which we won’t cover here):

public int myPublicInteger;
private int _myPrivateInteger;

As mentioned, the first of these two is a public variable, meaning we can easily access it from another class, whereas the private variable is only accessible and usable inside the class it’s declared in.

As a separate note, public variables will appear in Unity’s inspector for us to change and observe outside of the script itself. Private variables don’t support this by default, but we can make them support this by using an attribute before the variable declaration. Equally, we can choose to hide public variables if we want them to be accessible by scripts by not within the inspector:

[HideInInspector]
public int myPublicInteger = 0; // not visible in the inspector
[SerializeField]
private int _myPrivateInteger = 0; // visible in the inspector

Some Best Practices

It’s generally best to keep your variables private unless you’re confident you’ll need to directly reference and access them from another script. As for naming conventions, we tend to use camelCasing for variables and objects (or instances of a class or struct), but not for methods or class names, and we tend to put an underscore at the start of the names of private or protected variables. There’s not much to say we can’t name them with a different convention, for example using lower case and underscores (e.g. my_private_integer), just that it’s best to have some consistency with the convention you go with and that it should be as easy to read as possible. It’s also best to try to keep variable names short but descriptive, but this is sadly an art I’ve really yet to master.

Final notes

As a couple final notes, it’s worth noting that now all programming languages are ‘strongly typed’, meaning the compiler does a lot of the work in finding out what type the variable is based on it’s value. For instance:

let myVariable = "Hello World";

A compiler would be able to gather that ‘myVariable’ must be a string. C# is fairly strongly typed, but does support some use of ‘generics’ when we perhaps don’t know in advance what the type will be. The ‘var’ type will do just this, but you’ll need to initialise the variable in order for it to work:

var myVariable = 62.4f; // 'myVariable' will be interpreted as a float
var myOtherVariable = true; // 'myOtherVariable' will be interpreted as a bool

Appreciate some of this is more than we’ll immediately need to know when working with variables; I just find it helpful to recap on some of the main things I can remember learning about something as fundamental as variables.