Choosing Good Variable Names

One of the most important aspects of writing clear, understandable code is choosing appropriate names for your variables. Unreasonably long or incomprehensible identifiers should be avoided.

Although JavaScript allows you to give a variable a cryptic name like _$0_$, doing so in practice is a bad idea. Using dollar signs in your identifiers is highly discouraged; they are intended for use with code generated by mechanical means and were not supported until JavaScript 1.2. Despite its common use in practice, beginning an identifier with an underscore is also not a good idea. Variables internal to the interpreter often begin with two underscores, so using a similar naming convention can cause confusion.

A variable’s name should give some information about its purpose or value that is not immediately apparent from its context. For example, the following identifiers are probably not appropriate:

var _ = 10;
var x = "George Washington";
var foobar = 3.14159;
var howMuchItCostsPerItemInUSDollarsAndCents = "$1.25";

More apropos might be

var index = 10;
var president = "George Washington";
var pi = 3.14159;
var price = "$1.25";

You should also use appropriate names for composite types. For example,

var anArray = ["Mon", "Tues", "Wed", "Thurs", "Fri"];

is a poor choice of identifier for this array. Later in the script it is not at all clear what value anArray[3] might be expected to have. Better is

var weekdays = ["Mon", "Tues", "Wed", "Thurs", "Fri"];

which when later used as weekdays[3] gives the reader some idea of what the array contains. Function names are similar. A function to sum items could be called calc() but it might be better as sumAll().

Capitalization

Because JavaScript is case-sensitive, weekdays and weekDays refer to two different variables. For this reason, it is not advisable to choose identifiers that closely resemble each other. Similarly, it is not advisable to choose identifiers close to or identical to common objects or properties. Doing so can lead to confusion and even errors. Capitalization does, however, play an important role in naming conventions. JavaScript programmers are fond of the camel-back style for variable capitalization. With this convention, each word in a variable name has an initial capital except for the first. For example, a variable holding the text color of the body of the document might be named bodyTextColor. This convention is consistent with how properties of browser objects are named, so new programmers are strongly encouraged to adopt its use.

Short Variable Names

JavaScript programmers are fond of using very short variable names, like x, in order to decrease the number of characters that need to be transferred to the client. The reason is that fewer characters to send implies faster download time. Although the end user might notice some difference in download time for very large scripts, when compared to the size of typical images found in Web pages today, the several hundred characters saved by using short variable names is almost inconsequential. In addition, JavaScript stripped of comments and descriptive variable names is very hard to decipher, though that may be intentional. Consider that you may not want anyone reading or understanding your code. However, this can be a very bad thing if anyone else but you is expected to maintain or fix your scripts. It is possible to provide the best of both worlds by using any number of automated JavaScript “crunching” tools to carry out this task before you publish them to your Web site. In this sense, as with normal code, you would keep your original scripts intact in a readable form, but get the speed improvements of having crunched and obfuscated JavaScript on your site. One good tool for doing this is the W3Compiler found at www.w3compiler.com.

Consistent Variable Naming

If more than one person works on JavaScripts in your organization, or if you maintain a large collection of scripts (say, more than half a dozen), it’s a very good idea to adopt a naming convention for your variables. Developing and sticking to a consistent style of naming improves the readability and maintainability of your code.

Variable Scope and Functions

When a function is invoked, the interpreter creates a new local context for the duration of its execution. All variables declared in the function (including its arguments) exist only within this context. When the function returns, the context is destroyed. So, if you wish to preserve a value across multiple function calls, you might need to declare a global variable.

When a variable is referenced in a function, the interpreter first checks the local context for a variable of that name. If the variable has not been declared in the local context, the interpreter checks the enclosing context. If it is not found in the enclosing context, the interpreter repeats the process recursively until either the variable is found or the global context is reached.

It is important to note that the contexts are checked with respect to the source code and not the current call tree. This type of scoping is called static scoping (or lexical scoping). In this way, locally declared variables can hide variables of the same name that are declared in an enclosing context. The following example illustrates variable hiding:

var scope = "global";
function myFunction() 
{
 var scope = "local";
 document.writeln("The value of scope in myFunction is: " + scope);
}
myFunction();
document.writeln("The value of scope in the global context is: " + scope);

The result is shown in Figure 3-2. The local variable scope has hidden the value of the global variable named scope. Note that omitting var from the first line of myFunction would assign the value "local" to the global variable scope.

Figure 3-2: A local variable hides a global variable of the same name.

There are some important subtleties regarding variable scope. The first is that each browser window has its own global context. So it is unclear at first glance how to access and manipulate data in other browser windows. Fortunately, JavaScript enables you to do so by providing access to frames and other named windows. The mechanics of cross-window interaction is covered in later chapters, particularly Chapter 12.

The second subtlety related to scoping is that, no matter where a variable is declared in a context, it is visible throughout that context. This implies that a variable declared at the end of a function is visible throughout the whole function. However, any initialization that is included in the declaration is only performed when that line of code is reached. The result is that it is possible to access a variable before it is initialized, as in the following example:

function myFunction() 
{
 document.writeln("The value of x before initialization in myFunction is: ", x);
 var x = "Hullo there!";
 document.writeln("The value of x after initialization in myFunction
 is: ", x);
}
 myFunction();

The result is shown in Figure 3-3. Note how scope has undefined value before it is initialized.

Figure 3-3: Variables may be visible without yet being initialized.

The third subtlety has to do with static scoping. Consider the following code,

var scope = "global";
function outerFunction()
{
   var scope = "local";
   innerFunction();
}
function innerFunction()
{
   alert("The value of scope is: " + scope);
}
outerFunction();

which results in:

This example illustrates a critical aspect of static scoping: the value of scope seen in innerFunction is the value present in enclosing the global context: "global." It does not see the value set in outerFunction. That value of scope is local to that function and not visible outside of it. The correct value for scope was found by examination of the enclosing context in the original JavaScript source code. The interpreter can infer the correct value by “static” examination of the program text. Hence the name “static scoping.”

Variable Scope and Event Handlers

We saw that variables declared inside functions are local to that function. The same rule applies to JavaScript included in event handlers: the text of the event handler is its own context. The following script illustrates this fact. It declares a global variable x as well as a variable x within an event handler:

<<script type="text/javascript">>
  var x = "global";
<</script>>
<<form action="#" method="get">>
<<input type="button" value="Mouse over me first" 
  onmouseover="var x = 'local'; alert('Inside this event hander x is ' + x);" />>
<<input type="button" value="Mouse over me next! " 
  onmouseover="alert('Inside this event hander x is ' + x);" />>
<</form>>

Move the mouse over the first button to see that the value of x in that context has been set to "local". You can see that that x is not the same as the global x by then moving the mouse over the second button. The value printed by the second button is "global", indicating that the x set in the first handler was not the global variable of the same name.

Remember that because JavaScript is statically scoped, it’s only variables declared within the text of an event handler that have their own context. Consider this example:

<<script type="text/javascript">>
var x = "global";
function printx()
{
  alert("Inside this function x is " + x);
}
<</script>>
<<form action="#" method="get">>
<<input type="button" value="Mouse over me!" 
  onmouseover="var x = 'local'; printx();" />>
<</form>>

You can see that the value of x that is printed is "global". Static scoping at work again: Since the context of the function printx is global, it doesn’t see the local value set in the event handler text.

Execution Contexts

The preceding discussion of how variable names are resolved hints at the fact that execution contexts vary dynamically and reside within one another. For example, if a variable referenced in the text of an event handler cannot be found within that event handler’s context, the interpreter “widens” its view by looking for a global variable of the same name. You can think of the event handler’s local context as residing within the global context. If a name can’t be resolved locally, the enclosing (global) scope is checked.

In fact, this is exactly the right way to think about execution contexts in JavaScript. An (X)HTML document can be thought of as a series of embedded contexts: an all-enclosing JavaScript global scope within which resides a browser context, within which resides the current window. Inside the window resides a document, within which might be a form containing a button. If script executing in the context of the button references a variable not known in the button’s context, the interpreter would first search the form’s context, then the document’s, then the window’s, the browser’s, and eventually the global context.

The exact details of how this works comprise JavaScript’s object model, a subject discussed in later chapters. A comprehensive knowledge of the topic is not really required to program in JavaScript, but helps tremendously in understanding where the objects available to your scripts come from, and how they are related. It will also go a long way in setting you apart from the typical JavaScript developer!