JavaScript Debugger
JavaScript Editor
|
|
When studying a new programming language it is important to detail its major characteristics, such as how code is executed, whitespace is interpreted, statements indicated, and so on. This section covers these basic issues and should be understood before we talk about the various data types, operators, and statements provided by JavaScript.
JavaScript code found in (X)HTML documents is interpreted line by line as it is found in the page. This means that it is a good idea to put function definitions and variable declarations in the document head, enclosed by the <<head>> … <</head>> tags, if they will be used throughout the page. Certain code—for example, the bodies of functions and actions associated with event handlers—is not immediately executed.
JavaScript is case-sensitive. This means that capital letters are distinct from their lowercase counterparts. For example, if you use the identifiers result, Result, and RESULT in your script, each identifier refers to a separate, distinct variable. Case sensitivity applies to all aspects of the language: keywords, operators, variable names, event handlers, object properties, and so on. All JavaScript keywords are lowercase, so when using a feature like an if statement, you need to make sure you type if and not If or IF. Because JavaScript uses the “camel-back” naming convention, many methods and properties use mixed casing. For example, the M in the name of the lastModified property of the Document object must be uppercase; using a lowercase m will retrieve an undefined value.
The primary implication of case sensitivity is that you should pay close attention to capitals when defining and accessing variables, when using language constructs like if and while, and when accessing properties of objects. One typo can change the meaning of your whole script and require significant debugging effort.
| Note |
One exception to JavaScript’s case sensitivity is Internet Explorer 3. In this particular browser, client-side objects and properties are case-insensitive. This exception does not pose a problem for scripts you might write today. It merely means that some older scripts relying on Internet Explorer’s case insensitivity might not work in modern browsers. |
Under HTML 4 and earlier, element and attribute names are case-insensitive. For example, the following two tags are equivalent:
<<IMG SRC="plus.gif" ALT="Increment x" ONCLICK="x=x+1">> <<img src="plus.gif" alt="Increment x" onClick="x=x+1">>
This is not a problem in itself. The problem comes when novice programmers see HTML event handlers referenced in two different ways (like ONCLICK and onClick in the previous example) and assume event handlers can be accessed similarly in JavaScript. This is not the case. The corresponding event handler in JavaScript is onclick, and it must always be referred to as such. The reason that ONCLICK and onClick work in HTML is that the browser automatically binds them to the correct onclick event handler in JavaScript.
Consider also the following two tags, which are not equivalent:
<<img src="plus.gif" alt="Increment x" onclick="x=x+1">> <<img src="plus.gif" alt="Increment x" onclick="X=X+1">>
The reason they are not equivalent is that the first modifies the variable x, while the second modifies X. Because JavaScript is case-sensitive, these are two distinct variables. This illustrates an important aspect of HTML attributes: while the attribute name is not case-sensitive, its value may be. The onclick HTML attribute is not case-sensitive and so may be written onClick, ONCLICK, or even oNcLiCk. However, because the value to which it is set contains JavaScript, its value is case-sensitive.
Fortunately, with the rise of XHTML, which requires that element and attribute names be written in lowercase, the case sensitivity issue at the intersection between the two technologies is less murky. Developers should always assume case sensitivity and as far as markup goes, lowercase should always be favored.
Whitespace characters are those characters that take up space on the screen without any visible representation. Examples include ordinary spaces, tabs, and linebreak characters. Any sequence of excessive whitespace characters is ignored by JavaScript. For example
x = x + 1;
is the same as
x = x + 1;
This suggests that the use of whitespace is more for the benefit of the programmer than the interpreter. Indeed, thoughtful use of whitespace to offset comments, loop contents, and declarations results in more readable and understandable code.
| Note |
Because of JavaScript’s ambivalence to whitespace and most Web users’ frustration with slow download times, some JavaScript programmers choose to “compress” their scripts by removing excess whitespace characters either by hand or using a tool. |
The spacing between tokens can be omitted if the meaning is unambiguous. For example,
x=x+1;
contains no spaces, but is acceptable because its meaning is clear. However, most operations other than simple arithmetic functions will require a space to indicate the desired meaning. Consider the following:
s = typeof x; s = typeofx;
The first statement invokes the typeof operator on a variable x and places the result in s. The second copies the value of a variable called typeofx into s. One space changes the entire meaning of the statement.
There are two exceptions to the rule that JavaScript ignores excessive whitespace. The first is in strings. Whitespace will be preserved in any string enclosed in single or double quotes:
Experienced programmers might wonder what happens if you include a linebreak directly in a string. The answer involves another of the subtleties of whitespace and JavaScript: implicit semicolons and their relationship with statements.
Statements are the essence of a language like JavaScript. They are instructions to the interpreter to carry out specific actions. For example, one of the most common statements is an assignment. Assignment uses the = operator and places the value on the right-hand side into the variable on the left. For example,
x = y + 10;
adds 10 to y and places the value in x. The assignment operator should not be confused with the “is equal to” comparison operator ==, which is used in conditional expressions (discussed later in the chapter). One key issue with statements in a programming language is indicating how they are terminated and grouped.
Semicolons indicate the end of a JavaScript statement. For example, you can group multiple statements on one line by separating them with semicolons:
x = x + 1; y = y + 1; z = 0;
You can also include more complicated or even empty statements on one line:
x = x + 1; ;; if (x >> 10) { x = 0; }; y = y - 1;
This example increments x, skips past two empty statements, sets x to zero if x is greater than 10, and finally decrements y. As you can see, including multiple statements on one line is rather unwieldy, and should be avoided.
Although statements are generally followed by semicolons, they can be omitted if your statements are separated by a linebreak. For example,
x = x + 1 y = y - 1
is treated as
x = x + 1; y = y - 1;
Of course, if you wish to include two statements on one line, a semicolon must be included to separate them:
x = x + 1; y = y - 1
The formal rules for implicit semicolon insertion are a bit more complex than the preceding description would lead you to believe. In theory, tokens of a single statement can be separated by a linebreak without causing an error. However, if the tokens on a line without a semicolon comprise a complete JavaScript statement, a semicolon is inserted even if the next line could plausibly be treated as an extension of the first. The classic example is the return statement. Because the argument to return is optional, placing return and its argument on separate lines causes the return to execute without the argument. For example,
return x
is treated as
return; x;
rather than what was probably intended:
return x;
Therefore, relying on implicit semicolon insertion is a bad idea and poor programming style to boot. The practice should be avoided unless you are positive that you are aware of all the subtleties of JavaScript’s rules for semicolon insertions.
Curly braces ({ }) are used to group a list of statements together. In some sense you can think of the braces as creating one large statement (or code block). For example, the statements that make up the body of a function are enclosed in curly braces:
function add(x, y)
{
var result = x + y;
return result;
}
If more than one statement is to be executed as the result of a conditional or in a loop, the statements are similarly grouped:
if (x >> 10)
{
x = 0;
y = 10;
}
Regardless of their groupings, statements generally need to modify data, which is often in the form of a variable.
|
|
JavaScript Debugger
JavaScript Editor