Skip to main content

Section 3.3 Identifiers

The name a variable is given is formally called an identifier. There are certain rules that limit what you can use as an identifier and conventions that should guide your choices.

Subsection 3.3.1 Syntax Requirements

An identifier can be any sequence of letters and digits, but it must begin with a letter. It is also allowed to use the underscore character (_) in an identifier. Below are some examples of legal variable names and illegal ones:
Table 3.3.1. Legal and illegal identifiers
Identifier Legal/Illegal Note
age Legal
firstName Legal
x2 Legal
first_name Legal
2ndPlace Illegal Canโ€™t start with a digit
first name Illegal Canโ€™t use spaces
l%$* Illegal Can only use letters, digits, underscore
There are some words that are reserved in C++ and cannot be used as identifiers. These words include ones you have already encountered like int and using, you will encounter more as you learn more about the language. These reserved words are known as keywords. You can find a full list of keywords at cppreference, but you donโ€™t have to memorize them. Most programming editors provide โ€œsyntax highlightingโ€, which will use a different color for keywords. And the compiler will complain even if one does sneak past you and your editor.
Finally, it is important to recognize that identifiers are case-sensitive, so firstName is not the same as firstname or FirstName. That means it would be possible to have one variable named firstName and another named FirstName and use them to store two different values, but that would be a recipe for confusion.

Subsection 3.3.2 Conventions

Beyond the syntax requirements, there are also conventions for naming variables. For example, it is common to use lowercase letters for variable names, and to capitalize the first letter of each subsequent word in a multi-word name. For example, firstName is a common way to name a variable that stores a personโ€™s first name. This style of naming is called camelCase (the uppercase letters look a little like the humps on a camel). That is the style used in this book.
Another common style is snake_case, where words are separated by underscores, like first_name. Like other formatting choices, there is not a single โ€œrightโ€ way to name variables, but it is important to be consistent.

Note 3.3.1.

Case matters! If you get an error that looks like:
error: โ€˜mynameโ€™ was not declared in this scope
Double check that your identifier isnโ€™t actually myName
Another important consideration when naming variables is readability. The compiler does not care if you name your variables are all single letters or are random sequences of characters. But without comments, it is not clear to humans what these variables are for:
int t;  //time
int d;  //day
int m;  //month
int foo;  //year
Variables should always be given meaningful names that describe what data they are going to be used to store. A name like t does not indicate what the variable is for - if it is storing time, a temperature, or something else. Calling it time would be better. But if we were working with multiple times, we would want to be more specific and call it something like startTime or totalTime. Meaningful names like these help programmers understand code they are reading.
Good code is self documenting. The variable names and structure of the code make it easy to understand the intent of the programmer who wrote the code. Comments can be useful to help explain code, but they should never be thought of as a replacement for well chosen names.
Because we want to assign meaningful names for variables based on their purpose, you should not reuse variables for different purposes. If you declare a variable startTime, donโ€™t later use it to store a different value like โ€œendTimeโ€ or โ€œnumberOfClicksโ€.

Insight 3.3.2.

We write code as much for other people as for the computer. Code that makes sense to the compiler, but is difficult for humans to read is only fulfilling half of its purpose. Quality code is easy to read and understand, making it easier for others (and yourself) to work with it in the future.

Checkpoint 3.3.1.

You have attempted of activities on this page.