Chapter 3. Getting into the Details of Variables

Initially, computer programming appears difficult to beginners due to the way in which words are used in code. It's not the actual words that cause the problem because, for most of the part, many of the words are the same as those we use in our everyday life. C# is not a foreign language. The main problem is that the words simply don't read like typical sentences that we are all used to. You know how to say words and how to spell words. What you don't know is where and why you need to put them in that crazy-looking grammar, that is, the syntax that makes up a C# statement.

In this chapter, you will learn some of the basic rules to write a C# statement. We will also introduce many of the words that C# uses and the proper placement of these words in C# statements when we create our variables.

In this chapter, we will cover the following topics:

• Writing C# statements properly

• Using C# syntax to write variable statements

• The GameObject component's...

Writing C# statements properly

When you do normal writing, it's in the form of a sentence, with a period used to end the sentence. When you write a line of code, it's called a statement, with a semicolon used to end the statement.

Note

The reason a statement ends with a semicolon is so that Unity knows when the statement ends. A period can't be used because it is used in the dot syntax.

The code for a C# statement does not have to be on a single line as shown in the following example:

public int number1 = 2;

The statement can be on several lines. Whitespace and carriage returns are ignored, so, if you really want to, you can write it as follows:

public
int
number1
=
2;

However, I do not recommend writing your code like this because it's terrible to read code that is formatted like the preceding code. Nevertheless, there will be times when you'll have to write long statements—longer than one line. Unity won't care. It just needs to see the semicolon at the end.

Understanding component properties in Unity's Inspector

GameObjects have some components that make them behave in a certain way. For instance, select Main Camera and look at the Inspector panel. One of the components is the camera. Without that component, it will cease being a camera. It would still be a GameObject in your scene, just no longer a functioning camera.

Variables become component properties

Any component of any GameObject is just a script that defines a class, whether you wrote the script or the Unity's programmer did. We just aren't supposed to edit the scripts that Unity has written. This means that all the properties that we see in Inspector are just variables of some type. They simply store data that will be used by some method.

Unity changes script and variable names slightly

When we add our script to a GameObject, the name of our script shows up in the Inspector panel as a Component. Unity makes a couple of small changes. You might have noticed that when we added LearningScript...

Changing a property's value in the Inspector panel

There are two situations when you can modify a property value:

• During the Play mode

• During the development stage (not in the Play mode)

When you are in the Play mode, you will see that your changes take effect immediately in real time. This is great when you're experimenting and want to see the results.

Write down any changes that you want to keep because when you stop the Play mode, any changes you made will be lost.

When you are in the development mode, changes that you make to the property values will be saved by Unity. This means that if you quit Unity and start it again, the changes will be retained. Of course, you won't see the effect of your changes until you click on Play.

The changes that you make to the property values in the Inspector panel do not modify your script. The only way your script can be changed is by you editing it in the script editor (MonoDevelop). The values shown in the Inspector panel override any values you might have...

Private variables

Not all variables need to be public. If there's no need for a variable to be changed in the Inspector panel or be accessed from other scripts, it doesn't make sense to clutter the Inspector panel with needless properties. In LearningScript, perform the following steps:

1. Change line 6 to this:

   private int number1 = 2;

2. Then change line 7 to the following:

   int number2 = 9;

3. Save the file.

4. In Unity, select Main Camera.

You will notice in the Inspector panel that both properties, Number 1 and Number 2, are gone:

Line 6: private int number1 = 2;

The preceding line explicitly states that the number1 variable has to be private. Therefore, the variable is no longer a property in the Inspector panel. It is now a private variable for storing data:

Line 7: int number2 = 9;

The number2 variable is no longer visible as a property either, but you didn't specify it as private. If you don't explicitly state whether a variable will be public or private, by default, the variable will implicitly be private...

Naming your variables properly

Always use meaningful names to store your variables. If you don't do that, 6 months down the line, you will be sad. I'm going to exaggerate here a bit to make a point. I will name a variable as shown in this code:

public bool areRoadConditionsPerfect = true;

That's a descriptive name. In other words, you know what it means by just reading the variable. So 10 years from now, when you look at that name, you'll know exactly what it means. Now suppose that instead of areRoadConditionsPerfect, I had named this variable as shown in the following code:

public bool perfect = true;

Sure, you know what perfect is, but would you know that it refers to perfect road conditions? I know that right now you'll understand it because you just wrote it, but 6 months down the line, after writing hundreds of other scripts for all sorts of different projects, you'll look at this word and wonder what you meant. You'll have to read several lines of code you wrote to try to figure it out...

Beginning variable names with lowercase

You should begin a variable name with a lowercase because it helps distinguish between a class name and a variable name in your code. There are some other guides in the C# documentation as well, but we don't need to worry about them at this stage. Component names (class names) begin with a capital letter. For example, it's easy to know that Transform is a class and transform is a variable.

There are, of course, exceptions to this general rule, and every programmer has a preferred way of using lowercase, uppercase, and perhaps an underscore to begin a variable name. In the end, you will have to decide upon a naming convention that you like. If you read the Unity forums, you will notice that there are some heated debates on naming variables. In this book, I will show you my preferred way, but you can use whatever is more comfortable for you.

Using multiword variable names

Let's use the same example again, as follows:

public bool areRoadConditionsPerfect = true;

You can see that the variable name is actually four words squeezed together. Since variable names can be only one word, begin the first word with a lowercase and then just capitalize the first letter of every additional word. This greatly helps create descriptive names which the viewer is still able to read. There's a term for this, called camel casing.

I have already mentioned that for public variables, Unity's Inspector will separate each word and capitalize the first word. Go ahead! Add the previous statement to LearningScript and see what Unity does with it in the Inspector panel.

Declaring a variable and its type

Every variable that we want to use in a script must be declared in a statement. What does that mean? Well, before Unity can use a variable, we have to tell Unity about it first. Okay then, what are we supposed to tell Unity about the variable?

There are only three absolute requirements to declare a variable and they are as follows:

• We have to specify the type of data that a variable can store

• We have to provide a name for the variable

• We have to end the declaration statement with a semicolon

The following is the syntax we use to declare a variable:

typeOfData nameOfTheVariable;

Let's use one of the LearningScript variables as an example; the following is how we declare a variable with the bare minimum requirements:

int number1;

This is what we have:

• Requirement #1 is the type of data that number1 can store, which in this case is an int, meaning an integer

• Requirement #2 is a name, which is number1

• Requirement #3 is the semicolon at the end

The second requirement...

Assigning values while declaring a variable

Add some more variables to LearningScript using the types shown in the previous chart. While declaring the variables, assign them values as shown in the following screenshot. See how they are presented in the Inspector panel. These are all public variables, so they'll appear in the Inspector panel.

This screenshot shows what Unity presents in the Inspector panel:

The variables are displayed in the Inspector panel with the values set by default in the code. Remember that from now on, the value in the Inspector panel will override the value in the code, so if you decide to change your code a little, the value in Inspector will stay as it was initially.

Where you declare a variable is important

You will be declaring and using variables in many places in a script. The variables that I have shown you so far are called member variables. They are members of the LearningScript class—not declared within any method. These member variables are the only variables that have the option of being displayed in the Inspector panel or being accessed by other scripts.

Note

Declaring your member variables at the beginning of a class may give you a mental clue that these member variables can be used anywhere in the script.

We will also be creating variables in methods. These variables are called local variables. They are never displayed in the Unity's Inspector panel, nor can they be accessed by other scripts. This brings us to another concept of programming, called variable scope.

Variable scope – determining where a variable can be used

Variable scope is a fancy way of saying "Where in the script a variable exists." The following screenshot explains the scope of some variables:

You might have noticed that the rectangular blocks start and end with curly braces. Just like the AddTwoNumbers() method in Chapter 2, Introducing the Building Blocks for Unity Scripts, the code between an opening curly brace and a closing curly brace is called a code block. Absolutely wherever in a code you have an opening curly brace, there will be a closing curly brace to match. All of the code between the two braces is a code block. Notice that code blocks can be nested inside other code blocks.

Note

You normally won't create bare blocks of code with curly braces like I did in the case of Code Block 3. Code blocks usually include other things, such as if statements, looping statements, and methods. This example is just to demonstrate how the scope of a variable works and where a variable...

Summary

First, we covered how to write a C# statement, especially the semicolon for terminating a statement. All the component properties shown in the Inspector panel are member variables in the component's class. Member variables can be shown in the Inspector panel or accessed by other scripts when the variable is declared public. The type of data that a variable can store is specified when it's declared. Finally, you learned that variable scope determines where it is allowed to be used.

Now that you've learned about variables, you're ready to learn the details of the C# methods that will use the variables we create, which is the topic of the next chapter.