Case sensitivity
JavaScript is case sensitive. You must be aware of this when naming variables and using the language
keywords. A variable named remote is not the same as a variable named Remote or one named
REMOTE. Similarly, the loop control keyword while is perfectly valid, but naming it WHILE or While will result in an error.
Keywords are lowercase, but variables can be any mix of case that you’d like. As long you are
consistent with the case, you can create any combination you want. For example, all the following
examples are perfectly legal variable names in JavaScript:
buttonOne
txt1
a
C
White space
For the most part, JavaScript ignores white space, which is the space between statements in JavaScript.
You can use spaces, indenting, or whatever coding standards you prefer to make the JavaScript more
readable. However, there are some exceptions to this rule. Some keywords, such as return, can be
misinterpreted by the JavaScript interpreter when they’re included on a line by themselves.
Making programs more readable is a good enough reason to include white space. Consider the
following code sample. It includes minimal white space and indenting.
function cubeme(incomingNum) {
if (incomingNum == 1) {
return "What are you doing?";
} else {
return Math.pow(incomingNum,3);
}
}
var theNum = 2;
var finalNum = cubeme(theNum);
if (isNaN(finalNum)) {
alert("You should know that 1 to any power is 1.");
} else {
alert("When cubed, " + theNum + " is " + finalNum);
}
Now consider the same code with indenting.
function cubeme(incomingNum) {
if (incomingNum == 1) {
return "What are you doing?";
} else {
return Math.pow(incomingNum,3);
}
}
var theNum = 2;
var finalNum = cubeme(theNum);
if (isNaN(finalNum)) {
alert("You should know that 1 to any power is 1.");
} else {
alert("When cubed, " + theNum + " is " + finalNum);
}
The second code sample performs just like the first, but it’s easier to read and follow—at least it appears so to me! I find that it takes a short amount of time to actually write code but several years to work with it. When I visit the code a year later, I’m much happier when I’ve made the code more readable and easier to follow.
Comments
Speaking of creating more readable code and maintaining that code over the long term: Comments are your friends. Code that seems blatantly obvious now won’t be nearly so obvious the next time you look at it, especially if a lot of time has passed since you wrote it. Comments can be placed into JavaScript code in two ways: multiline and single-line.
A multiline comment in JavaScript will look familiar to you if you’ve coded in the C programming language. A multiline comment begins and ends with /* and */, respectively, as the following code example shows:
/* This is a multiline comment in JavaScript
It is just like a C-style comment insofar as it can
span multiple lines before being closed. */
A single-line comment begins with two front slashes (//) and has no end requirement because it spans only a single line. An example is shown here:
// Here is a single-line comment.
Using multiple single-line comments is perfectly valid, and I use them for short comment blocks rather than using the multiline comment style previously shown. For example, look at this block of code:
// Here is another comment block.
// This one uses multiple lines.
// Each line must be preceded with two slashes.
Semicolons
Semicolons are used to delineate expressions in JavaScript. Technically, semicolons are not required
for most statements and expressions. However, the subtle problems that you can encounter when
you don’t use semicolons add unnecessary errors and hence unnecessary debugging time. In some
instances, the JavaScript interpreter inserts a semicolon when you might not have wanted one at all.
For example, consider this statement:
return
(varName);
In all likelihood, you wanted to write:
return(varName);
But JavaScript, acting on its own, inserts a semicolon after the return statement, making the code
appear like this to the JavaScript interpreter:
return;
(varName);
This code won’t work; the interpreter will misunderstand your intentions. If you used this code
in a function, it would return undefined to the caller, which is unlikely to be what you want. This is
an example where free use of white space is not allowed—you can’t successfully use line breaks
(explained in the next section) to separate the return keyword from the value that it’s supposed to
return.
But you definitely shouldn’t use semicolons in one instance: when using loops and conditionals.
Consider this bit of code:
if (a == 4)
{
// code goes here
}
In this case, you wouldn’t use a semicolon at the end of the if statement. The reason is that the
statement or block of statements in opening and closing braces that follows a conditional is part of
the conditional statement—in this case, the if statement. A semicolon marks the end of the if statement,
and if improperly placed, dissociates the first part of the if statement from the rest of it. For
example, the following code is wrong (the code within the braces will execute regardless of whether a
equals 4):
if (a == 4);
{
// code goes here
}
Line breaks
Related closely to white space and even to semicolons in JavaScript are line breaks, sometimes called carriage returns. Known in the official ECMA-262 standard as “Line Terminators,” these characters separate one line of code from the next. Like semicolons, the placement of line breaks matters. As you saw from the example in the previous section, placing a line break in the wrong position can result in unforeseen behavior or errors.
Not surprisingly, the most common use of line breaks is to separate individual lines of code for readability. You can also improve readability of particularly long lines of code by separating them with line breaks. However, when doing so, be aware of issues like the one illustrated by the return statement cited earlier, in which an extra line break can have unwanted effects on the meaning of the code.