Variable Names (What You Should Must Know Before Writing Code!)

It’s important to know that variable identifiers and class identifiers can be pretty much anything. There are some rules to naming anything when programming. Here are some guidelines to help. Long names are more prone to typos, so keep identifiers short. A naming convention for variables should consider the following points.
The variable name should indicate what it’s used for, or at least what you’re going to do with it. This should be obvious, but a variable name shouldn’t be misleading. Or rather, if you’re using a variable named radius, you shouldn’t be using it as a character’s velocity. It’s also helpful if you can pronounce the variable’s name; otherwise you’re likely to have issues when trying to explain your code to another programmer.

int someLong_complex_hardToRememberVariableName;

There is an advantage to keeping names as short as possible but still quite clear. Your computer screen, and most computers for that matter, can only fit so many characters on a single line. You could make the font smaller, but then you run into readability issues when letters get too small. Consider the following function, which requires more than one variable to work.

SomeCleverFunction(TopLeftCorner – SomeThickness + OffsetFromSomePosition, BottomRightCorner – SomeThickness + OffsetFromSomePosition);

The code above uses many long variable names. Because of the length of each variable, the statement takes up multiple lines making a single statement harder to read. We could shorten the variable names, but it’s easy to shorten them too much.

CleverFunc(TL–Thk+Ofst,LR–Thk+Ofst);

Variable names should be descriptive, so you know what you’re going to be using them for: too short and they might lose their meaning.

int a;

While short and easy to remember, it’s hard for anyone else coming in to read your code and know what you’re using the variable a for. This becomes especially difficult when working with other programmers. Variable naming isn’t completely without rules.

int 8;

A variable name can’t be a number. This is bad; numbers have a special place in programming as much of it has other uses for them. MonoDevelop will try to help you spot problems.
A squiggly red line will appear under any problems it spots. And speaking of variable names with numbers, you can use a number as part of a variable name.

int varNumber2;

The above name is perfectly valid, and can be useful, but conversely consider the following.

int 13thInt;

First Steps
Variable names can’t start with any numbers. To be perfectly honest, I’m not sure why this case breaks the compiler, but it does seem to be related to why numbers alone can’t be used as variable names.
int $;
int this-that;
int (^_^);

Most special characters also have meanings, and are reserved for other uses. For instance, in C#, a - is used for subtracting; in this case C# may think you’re trying to subtract that from this. Keywords, you should remember, are also invalid variable names as they already have a special meaning for C#. In MonoDevelop, you might notice that the word this is highlighted, indicating that it’s a keyword. Spaces in the middle of a variable are also invalid.

int Spaces are bad;

Most likely, adding characters that aren’t letters will break the compiler. Only the underscore and letters can be used for identifier names. As fun as it might be to use emoticons for a variable, it would be quite difficult to read when in use with the rest of the code.

int ADifferenceInCase;
int adifferenceincase;

The two variables here are actually different. Case-sensitive languages like C# do pay attention to the case of a character; this goes for everything else when calling things by name. Considering this: A is different from a.

NOTE:
Trained programmers are often taught a variation of naming conventions, which yields easier-to-read code. Much of this is dependent on scope, which we will discuss in Section 4.4.4. There are also conventions which always prefix variable names with an indication of what sort of data is stored by that variable.
As a programmer, you need to consider what a variable should be named. It must be clear to you and anyone else with whom you’ll be sharing your work with. You’ll also be typing your variable name many times, so they should be short and easy to remember and type.
The last character we discuss here is the little strange @ or at. The @ can be used only if it’s the first character in a variable’s name.

int @home;
int noone@home;

In the second variable declared here we’ll get an error. Some of these less regular characters are easy to spot in your code. When you have a long list of variables it’s sometimes best to make them stand out visually. Some classically trained programmers like to use an underscore to indicate a class scope variable. The underscore is omitted in variables which exist only within a function.
You would find the reason for the odd rule regarding @ when you use int, which is reserved as a keyword. You’re allowed to use int @int, after which you can assign @int any integer value. However, many programmers tend to use MyInt, mInt, or _int instead of @int based on their programming upbringing.

Good programmers will spend a great deal of time coming up with useful names for their variables and functions. Coming up with short descriptive names takes some getting used to, but here are some useful tips. Variables are often named using nouns or adjectives as they describe an attribute related to what they’re used for.

A human character can often have a health attribute.
Naming this HealthPoints or NumberOfHealthPoints is sometimes considered too wordy, or even redundant. However, if you and your friends are accustomed to paper role-playing games then perhaps HitPoints would be preferred.
In the end once you start using the name of the variable throughout the rest of your code, it becomes harder to change it as it will need to be changed everywhere it’s used. Doing a global change is called refactoring, and this happens so often that there is software available to help you “refactor” class, variable, and function names.

NOTE: You may also notice the pattern in which uppercase and lowercase letters are used.
This is referred to as either BumpyCase or CamelCase. Sometimes, the leading letter is lowercase, in which case it will look like headlessCamelCase rather than NormalCamelCase.
Many long debates arise between programmers as to which is correct, but in the end either one will do. Because C# is case sensitive, you and anyone helping you should agree whether or not to use a leading uppercase letter.
These differences usually come from where a person learned how to write software or who taught that person. The use of intermixed uppercase and lowercase is a part of programming style.
Style also includes how white space is used.
When you name variables in Unity 3D the use of CamelCase or BumpyCase will automatically separate the different words indicated by an uppercase letter in the Inspector panel.
This doesn’t actually affect how the declaration was written. This will only change how your variable’s name appears in the Unity 3D editor.