Section 3.1. Format of a JavaScript Statement

3.1. Format of a JavaScript Statement

JavaScript statements terminate with a semicolon, though not all statements need the terminator expressly given. If the JavaScript engine determines that a statement is complete (whatever that is for each type of statement), and the line ends with a new line character, the semicolon can be omitted:

var bValue = true var sValue = "this is also true"

If multiple statements are on the same line, though, the semicolon must be used to terminate each:

var bValue = true; var sValue = "this is also true"

However, not explicitly terminating each JavaScript statement is a bad habit to get into, and one that can result in unexpected consequences. As such, the use of the semicolon to terminate JavaScript statements is a JavaScript best practice.

JavaScript Best Practice: Explicitly terminate JavaScript statements with the semicolon, whether or not it's required.

The use of whitespace in JS has little impact on the code. For instance, the following two lines of code are interpreted exactly the same:

var firstName = 'Shelley'     ; var firstName = 'Shelley';

Other than to delimit words within quotes or to terminate statements, extra whitespacesuch as tabs, spaces, and new linesis disregarded. In the following code, the variable assignment completes successfully, even though there is a line terminator separating the statement:

var firstName  = 'Shelley'; alert(firstName);

The engine didn't interpret the end-of-line character as a statement terminator in this instance because it evaluated the code and determined that it was incomplete. The JavaScript engine continues to process what it finds until either the semicolon is reached or until a statement is completed. In the case of the assignment statement, this state is reached when the right-side expression of the statement is provided.

Deciding whether to interpret an end-of-line terminator as a statement terminator is all a part of JavaScript's forgiving nature: JavaScript works on the side of successfully processing the code and does whatever is needed to facilitate this. Well, unless doing so introduces confusion. In the following code:

var firstName =  var lastName = 'Powers';

The JavaScript engine returns an error because the second line doesn't evaluate to a correct right-side assignment.

Returning to the discussion of whitespace, indentation is used throughout the book to make the examples more readable, but there's no programmatic reason to indent a line with a tab or spaces. The same holds true for whitespace surrounding operators such as assignment (=) or one of the math operators (such as +). Whitespace isn't necessary. Whitespace and comments, as well as meaningful identifiers, are there to make the code easier to maintain.

JavaScript "Compression"

The reasons to add whitespace make sense: readability, separation of key language elements, line termination, and so on. But what about removing such space?

JavaScript compressors take all noncode-specific whitespace out of a JavaScript application. The concept behind such tools is the more whitespace you put into JavaScript, the slower the download and the more client resources you consume. There are tools and sites that provide compressed JS, such as Packer, at http://dean.edwards.name/packer/ (shown in Figure 3-1) and a host of others listed at Web Tools by Radok, at http://www.radok.com/javascript-compression.html.

Are these necessary? With small scripts, no, of course not. For larger JavaScript files? Hard to say: even the most complex JS library isn't more than a few hundred lines. Usually, I should add, because some of the newer Ajax libraries can be quite large.

Still, web pages today have 200K photos embedded in them and links to resource material served from half a dozen sites. Does the size of a JS library have as much of an impact as it once did? Again, it depends on the page, and what you know of your client's expectations and environments.

There are reasons not to use compression. If an error is introduced into the code, the compression makes it difficult to debug. The code is also unreadable, which inhibits sharing, a hallmark of the scripting community.

Of course, sometimes you want to limit sharing. The very nature of compressionobfuscationmay be one reason to use compressors. As Figure 3-1 demonstrates, Packer doesn't just compress the code, it also obfuscates it, making it difficult (if not impossible) to copy. There are several encryption and obfuscation tools that can make JS completely unreadable, though most (unlike Packer) are commercial products.

Figure 3-1. Packer, a JavaScript compression service