If we could look inside a program while it was running, we'd see many individual pieces of data such as the email address of a member, the score in a game, the url of a website, the date of an event, whether a user is logged in or not. In your program, you do this by creating variables.
Creating variables is how your program can claim a piece of computer memory to use while it's running. Give it a name and then you can then refer to that piece and use it in your source code.
There are 3 things to think about for every variable: its name, its value, and its type.
Let’s go back to the idea of keeping track of the score in a game. If this was a variable, the name would be score, the value might begin at zero, then change to a hundred, a thousand or a million. It's like having the little box shown in Fig 3.2.1.
Fig 3.2.1: Representation of a variable
This container that we've given a name to the name stays the same, but the value inside can change from moment to moment. It can vary, which is why it's called a variable. Then there's the type, that is, what type or what kind of data do we want to put in each variable? Will this be text or is it numeric? Is it a simple yes or no? True or false? Or is it a currency amount or a million email addresses all grouped together? Is it our company logo?
Programming languages care deeply about the type of each piece of data because it affects how much memory is needed for every variable.
If you make a variable and then you code, you can tell the computer the value of that variable will only ever be true or false, but nothing else. The computer only needs to set aside a tiny piece of memory to keep track of that.
But if you want another variable that could contain all the texts from the first 28 chapters of a book, or hold all the sales numbers in the last quarter, hold an image or a piece of video, then the computer needs to grab a bunch more memory to store something like that.
So in Fig 3.2.1, the new variable “score” will be just a simple numeric value. We might change that value but it will always be a whole number with nothing after the decimal point. It's an integer.
So if that’s the idea, how do you actually do this? Well in many languages you must declare a variable before you use it. What that means is you write a statement in your source code to say you want to make a new variable, you need to say what its name is and often say what type of data it is. It’s only after you have declared it can you then give it a value and start changing that value.
The exact syntax for this of course differs between languages, but a few examples are shown in Fig 3.2.2. Once again, I'll point out I am not looking for you to memorize any of the syntax. Just observe, begin to notice some of the similarities and the differences.
Fig 3.2.2: How to declare variables in some languages
In the Swift language var is the keyword to create a new variable. Score is just our name for this new variable and :int is Swift’s way of saying this new variable must always be an integer. Any attempt to put in a different kind of value like a date or a piece of text would cause an error.
In a Visual Basic program, it's Dim score As Integer. Dim is an older term and a short for dimension. It’s a way to tell the computer go grab an area of memory for a new variable, and “As integer” is the type of data we have.
In C++, it's a very short succinct format. Just int score. We don't need a keyword like var or dim because in this language, just using the word int this way makes a new integer variable called score.
In JavaScript it's var score. The word var similar to Swift is ysed to declare the variable. But unlike the other three, we don't have anything in JavaScript to say this is an integer and that's because JavaScript is a language where you don't have to provide a type for each variable.
However, in all of these codes, the word score was totally my choice. This could have been “playerscore” or “currentscore” or whatever else I wanted. The name is also called the identifier of each variable and is up to us to choose.
Still within each language, there’re two things to know: what is allowed when you're naming variables and what is expected when you're naming them. See Fig 3.2.3.
Fig 3.2.3: What to know before choosing a variable name (identifier)
There are few rules you must follow. There are things you just can't use as a name and would cause an error if you try. On top of those rules, there are also guidelines for how you should name things.
Let me use Javascript as a simple example, but this is true in most other languages. See Fig 3.2.4.
Fig 3.2.4: A Javascript example of a variable name
There is nothing stopping me declaring a variable called CuRReNt_Sc0_rE, that is, writing the name (identifier) in a mixture of uppercase and lowercase with a 0 (zero) instead of the letter O because it does not violate the syntax, the actual rules of the language. This means I won't get an error if I do this, but it's not an accepted style.
For example, if I was on the team of developers, I'd expect the others to say, what are you doing here? Why did you write it this way? But let's cover the few rules about naming first. Oh yes, there are always going to be exceptions and edge cases, so assume that right now I'm going to show you what's true for most current popular programming languages most of the time.
Fig 3.2.5: Some unacceptable variable names
First, no reserved words, that is, you can't name a variable using a word the language already owns. You can't create a variable called if or true or any of the other keywords that are words that that language wants to use.
Beyond that, most languages support naming your variables using any combination of letters, numbers, and a few special characters like underscores, just written in all lowercase like score which is very common to see. Bear in mind as already discussed, most languages are case sensitive. So, there's a difference between a variable named score with a lowercase first letter and a variable name score with an upper case first letter.
Now there's nothing that actually forces you to use real words. It's just good practice to make your variable names readable and understandable. In a few languages you'll see special characters at the beginning of each name, each identify like underscore, hash or pound signs. PHP for example requires the dollar sign. See Fig 3.2.6.
Fig 3.2.6: Some unacceptable variable identifiers
Beyond that, in most programming languages, you can't use spaces in a variable name. The identifier must be all one piece. So, if you have multiple words, there are different styles to keep them together. We're going to talk about that in a few moments.
Some modern programming languages go beyond just allowing the Roman alphabet. They support other alphabetic systems, even emojis.
Fig 3.2.7: Some acceptable non-Roman identifiers
Well, okay, you wouldn't actually create a variable called smiley face-frowny face. It's simply a side effect that in some programming languages you can use anything that's allowed on a multinational keyboard, whether that's Mandarin or Hebrew or Arabic or emoji.
But one common syntax restriction is that while you can have numbers in your variable names, you cannot begin that name with a number. The reason is that if you could, then you could also end it with a number and create variables that just look exactly like numeric values.
For example, a variable called 99 would be confusing all around.
Fig 3.2.8: A naming rule where a variable name cannot begin with numbers but can end with it
With these rules in mind, here's an example of what I mean by a style guideline. Across many languages, there’s a common style or convention for naming a variable. It is to use camel case. So, if the variable name (the identify that you want) is just a single word like score, name or department, it's just written on all lowercase.
But often a single word isn't good enough. It's not specific enough because you want your variable names to be obvious for anyone to read that name and immediately understand why it exists. So, we often need two or more words.
Let's say score isn't good enough. We need both playerScore and highScore variables. Then we just put those words together and we would capitalize every word after the first. It's like the hump of a camel (camel case).
Fig 3.2.9: The Camel case style showing how one-word variables are used to create multiple-word variable names
An alternative style would be to use underscores to separate multiple words. In many languages you could technically write it either way. You could use both of them, you could write them all uppercase or lowercase. There's nothing that would stop you.
But you'd find that a typical style like camel case becomes the convention, the standard way to do it in each language. Adopting that standard style makes it much easier for you to read other developers’ source codes and for them to read yours.