Specifically, we'll start with a very quick review of creating and using variables, then moving over to consider the different variations of defining variables using
typeof, and seeing the more recent way of defining variables using
A quick review
Shown below is the syntax of defining a variable using
var variableName = value;
var keyword is followed by the name of the variable to create (denoted as
variableName), followed by an equals sign (
=), followed by the initial value to assign to the variable (denoted as
The first part in this statement, i.e.
var variableName, is usually known as the variable's declaration. It serves to introduce a new identifier into the execution environment.
The second part, i.e.
= value, is usually known as the variable's initialization. As the name suggests, it serves to set the variable to an initial (starting) value at the time of its declaration.
To change the value of an existing variable, we just use the same equals sign (
=) followed by the new value to put inside the variable, as shown below:
variableName = newValue;
This statement is commonly referred to as the variable's assignment.
In the code below, we define two variables
y holding the values
var x = 10; var y = 20;
Working with these variables is just working with the numbers
20 directly. That is, we can add them, multiply them, log them, assign them to other variables, and so on and so forth.
Following, we experiment around with the variables
y created before:
var x = 10; var y = 20; console.log(x); console.log(y); console.log(x + y); console.log(50 * x * y);
Let's consider another example, this time changing the value of the variable amid the program:
var x = 10; console.log(2 ** x); x = 5; console.log(2 ** x)
x is equal to
10 and so the expression
2 ** x becomes
2 ** 10 which evaluates to
1024. Next up,
x is changed to
5, and likewise the expression
2 ** x becomes
2 ** 5 which evaluates to
This illustrates how we could change the value of a variable at any point in a program.
Alright, it's time for a quick task.
Write a piece of code to accomplish the following.
Create a variable
text holding the text shown below,
The ' character is called an apostrophe.
and then log the text to the console.
Since the given text contains a single quote (
') character in it, we'll denote the string using a pair of double quotes (
var text = "The ' character is called an apostrophe."; console.log(text);
Variations of using
While creating variables using
var, there isn't just one fixed syntax for doing so. We can change it according to our need and preference.
Let's see what this means.
Suppose we want to create three variables
z holding the values
The obvious way to do this is as follows:
var x = 10; var y = 20; var z = 30;
Each variable is defined separately, on a new line, with a separate
Another way is to just use
var once and then define all the individual variables one-by-one, without having to type
var again and again.
Syntactically, this could be expressed as this:
var variableName1 = value1, variableName2 = value2, variableName3 = value3, ... variableName3 = value4;
Everything is the exact same as before, with the exception of the
var keyword and the last character — previously it was a semicolon (
;) to indicate the end of the statement, but now it's a comma (
When a variable definition ends with a comma (
,), it means that more variable definitions follow along. It's only when we put a semicolon (
;) in the end that the parser figures out that the variable definitions have ended.
So going with this approach, the same code above could also be expressed as follows:
var x = 10, y = 20, z = 30;
Note that there is no semicolon at the end of the first line, neither at the end of the second line. The semicolon is only appended to the third line where it ends the whole set of definitions.
Now which variation shall we use?
Well, it's totally a matter of preference.
We'll go with our old method of using a new
var keyword for each variable definition.
This is because we feel that it keeps the code readable and doesn't introduce any awkward indentation before all the subsequent variable definitions after the first one. But more importantly, there is always a chance of clerical errors when using the one-
The problem with using
, in variable definitions
When using commas (
,) with the
var keyword, there is always a chance to make a typo and use
; instead of
, at the end of a variable definition which is followed by another definition.
This can modify the meaning of the following variable definition statement completely.
To understand what this means, consider the code below:
var x = 10; y = 20, z = 30; console.log(x + y + z);
Everything looks fine at first glance, so let's go on and run this.
Here's what gets displayed in the console:
Although, we did indeed get the expected output, we forget to fix a typo in the code. Can you spot it?
The first variable definition statement was meant to end with
, but it instead ended with
'use strict' at the start of the script.
Here's the code above rewritten to leverage strict mode:
'use strict' var x = 10; y = 20, z = 30; console.log(x + y + z);
Now when we run it, here's what gets displayed in the code:
The strict mode is able to pick up the typo and raise an error. Since the code seemed absolutely fine to us, after seeing this error, we immediately inspect the code and spot the
; typo in line 1 at the end of the statement. Great.
We'll learn more about strict mode later on in this unit.
At this point, it might definitely seem that using commas to define multiple variables at once is not useful at all.
Well, that's not the case.
If we are just wanting to declare multiple variables at once without initializations, then the comma syntax proves to be really concise.
As you can see in the syntax below, it's possible to omit the initialization from a variable definition — what we're left with then is just the declaration:
When this statement executes, the variable comes into existence with the initial value
Alright, let's come back to the point.
Suppose we want to declare three variables
z but not assign them any value at the moment. Using this short syntax, we can simply declare them all at once by separating each variable with a comma (
The code below demonstrates this:
var x, y, z;
Now compare this with:
var x; var y; var z;
Which one is more readable and concise?
Clearly the first one. This is the syntax we'll use throughout this course when we want to declare multiple variables at once without any initializer.
Rules for naming variables
Almost all programming languages enforce certain rules on the programmer when naming variables. This is done to prevent one from creating names that could introduce ambiguity into the respective program.
- Names can only contain alphanumeric characters (a-z, A-Z, 0-9) and the
$(dollar sign) characters; nothing else. Hence,
first-nameis invalid since it contains a hyphen (
-) which is illegal to put in a variable name.
- Names can't begin with a digit. Hence,
- Names can't contain spaces. Hence,
first wordis invalid.
- Names can't be reserved keywords. Hence,
Tips for naming variables
A variable's name shall clearly describe what it's meant to hold.
For instance, suppose that you have to store a user's name in a variable. It would be really bad if you name the variable
u for 'user', or any random character). The name
a doesn't tell much about what's stored in the variable.
A much better name would be
Well frankly speaking, the latter, i.e.
uname, is also not very descriptive and sometimes could be ambiguous —
uname could also stand for 'universal name', 'unsatisfactory name', or maybe even 'unique name'.
Don't be overly descriptive
Creating descriptive variable names is desirable, but we have to make sure that we remain within the bounds of description. Even too much description can be problematic.
Suppose we want to create a variable that stores the first name of a user. Being exceptionally descriptive, we could name it
thefirstnameofuser, although this would be more than the required amount of description.
A better name would be
We have to remain in between the scale of descriptiveness — not too little, and not too much.
Abbreviate long words
Sometimes, it's really helpful to abbreviate long words in a given name to short and simple words, given that the abbreviation seems sensible.
For example, the variable
dbname could work well instead of
databasename. Here, we've abbreviated 'database' to 'db'.
But keep in mind that abbreviations don't always work well.
For instance, naming a variable that holds the name of an object's property as
pname would be a complete mess.
pname could mean 'property name' or 'panel name' or 'previous name'.
A much better name would be
propname — with the word 'property' abbreviated down to 'prop'.
Use a casing convention to break words
When a variable's name contains more than one word, it's desirable to use some casing convention to be able to distinguish between them easily while reading the variable.
Let's say we have a variable
questionsasked that holds the number of questions asked in a quiz program. Seeing this name doesn't rightaway tell us about the individual words in it. Does it?
We have to gaze at the name for a while before we realize that it says 'questions asked'.
Worse yet, in some words the name could even be misinterpreted by the reader. For example, what can you read in
idenum? Did you read it as 'ide num' or as 'id enum' ?
Well, the variable meant 'id enum' for 'ID enumeration'.
So to solve such ambiguities and make long variable names readable, we ought to use casing conventions.
Some common casing conventions are as follows:
- PascalCasing: every word's first character is uppercased. C# uses Pascal casing for almost all identifiers. Some examples from C# are as follows:
- snake_casing: every word is lowercased and separated from the other using the
_(underscore) character. PHP uses snake casing for most of its predefined functions. Some examples from PHP are as follows:
- SCREAMING_SNAKE_CASING: every word is uppercased and separated from the other using the
Coming back to our example, the variable
questionsasked could be renamed to one of the following:
questionsAskedin camel casing.
QuestionsAskedin Pascal casing.
questions_askedin snake casing.
QUESTIONS_ASKEDin screaming snake casing.
Now it doesn't require much effort on our side to distinguish between the different words used in the variable's name.
But which one of these should we use?
The two most common conventions used for naming variables in most of the programming languages out there are camel casing and snake casing.
Honestly speaking, this is solely a matter of preference. If you like camel casing, go with it. Similarly, if snake casing appeals you, go with it. Whatever you choose, make sure to stick with it — consistency is a must!
Long story short, naming isn't any scientific theory to learn — it's purely an art.
In your journey of programming, you'll be able to come up with extremely effective variable names with:
- Experience — the more you code, the better you become at naming.
- Lots of trial and error — keep on altering the name of the variable until you feel that it communicates its underlying purpose in the best way.
Checking for a variable's existence
For instance, consider the code below:
We log the variable
x and get an error thrown back at us. It's simply because there isn't any definition of
x anywhere in the code.
The way we check for the existence of a variable is via
typeofoperator basically returns the type of a given value.
Here's its syntax:
value is the value whose type we ought to determine.
When provided with a non-existent variable,
typeof returns the string
'undefined'. This return value can be used to determine whether a variable is accessible or not.
That is, we can compare the return value of
typeof as applied on a non-existent variable with the string
'undefined' using the non-equality (
The non-equality operator, denoted as
!==, compares two values together and determines whether they are not equal to one another. If the given values are not equal, it evaluates down to the Boolean value
true, or else to
For example, consider the code below:
var x = 10; console.log(typeof x !== 'undefined'); console.log(typeof y !== 'undefined');
Here we define a variable
x and then check whether it exists or not, by comparing
typeof x with
'undefined' for equality. Since
x exists, we get
true output by the first log statement. However, since there is no such variable as
y, the second log statement outputs
typeof, doing the same doesn't lead to any errors whatsoever. This is because the internal engine is configured to treat non-existent variables differently when used in a
Moving on, one extremely important thing to keep in mind while performing such a variable existence check is that
'undefined' even for a variable that's declared but not assigned a value.
This can be seen as follows:
console.log(typeof x !== 'undefined'); var y; console.log(typeof y !== 'undefined');
Here, the variable
x doesn't exist and so
typeof x returns
'undefined'. However, the variable
y does exist, yet it faces the same fate as
x. That is,
typeof y also returns
For us, this means that if we get
'undefined' returned by
typeof while inspecting a given variable, then we can NOT be definitely sure that the variable doesn't exist.
However, at least we can safely assume that the variable isn't of use to us (either because it's non-existent or not assigned a value) and hence not proceed with consuming its value for any purpose in our program.
Enjoyed reading so far? 👌
Send us your feedback for this chapter on email@example.com. We'd love to hear about your views for this chapter and CodeGuage, in general!Send message ↗
var declarations in there are put into action before executing any other statement in the code.
This is formally known as variable hoisting.
In practice, hoisting seems to bring all variable declaration statements to the top-most location of wherever they are defined.
In reality, however, there isn't anything such as 'bringing the variable declarations up' — it's just an analogy drawn to help the developer understand what essentially is happening.
Although no one would ever want to do this, it's a feature to be aware of so that we don't mistakenly write code that executes contrary to how we expect it to.
For instance, consider the following code:
str = 'Hoisting'; console.log(str); var str;
Despite the fact that we assign a value to the variable
str in line 1 before it's actually declared in line 4, this code doesn't flag any errors whatsoever, even though it should've.
That's because during execution, it's the same as the following code:
var str; str = 'Hoisting'; console.log(str);
This is due to the effect of the hoisting of
For example, consider the following code:
console.log(str); var str2 = 'Hoisting';
As is apparent by the
undefined log, only the declaration of
str here (in line 3) is hoisted, NOT its initialization
let creates block-scoped variables. In contrast,
let is akin to
let variableName = value;
In the code below, we define two variables
let and use them just how we've been used to using variables uptil now:
let x = 10; let y = 20; console.log(x + y); console.log(x * y); console.log(x / y + y);
If we want to, we can define multiple variables at once with
let by separating their declarations with a comma (
,). We can even omit the initialization of variables.
Consider the following code where we define three variables using
let and then set them later on:
let x, y, z; x = 10; y = 20; z = 30; console.log(x + y + z);
var, isn't it?
let differs from
var in that
let declarations are not hoisted.
let variable before its declaration leads to an error; the standard refers to such a scenario as a temporal dead zone.
letvariable is simply referred to the region prior to the variable's declaration in the source code, where we can NOT access the variable.
Remember that the temporal dead zone doesn't apply to
letvariable is by analyzing all
letdeclarations before running the code. Then the region before the
letdeclaration becomes a temporal dead zone for the respective variable.
Let's see an example.
In the code below, we try to access the variable
x before it's declared (via
console.log(x); let x = 10;
Since the access is made in the temporal dead zone of the variable, we get an error:
let is exactly — in fact, only — what allows us to do this.
As we saw in the sections above, if rewrite this same code using
var, no errors would be thrown, and that's because of the effects of
What to use:
This is a really good question, the answer to which is purely preferential and sometimes even dependent on the problem being solved.
var is poor in performance than
let'. It isn't at all inefficient to use
var in modern code.
In fact, for newbie developers, understanding how
var works and how it differs from
let is important to be able to truly appreciate the power of
let in certain use cases and also realize that there isn't any reason to believe that
var might perform poorly than
There surely are certain places where using
let can simplify code drastically, but majority of the times, there isn't much of a difference if we use
So, to answer the question: if you want to, you could surely switch to using
let instead of
var, or keep using the latter. It's mostly, if not completely, a preferential choice.
But whatever you choose, make sure to stay consistent with it.
Throughout this course, however, we stick to using
var and that's because we've been using it for a very long time now and so changing all the existing code to use
let won't be very feasible. But all the code examples shown can easily be swapped with