WebReference.com - Chapter 2 of JavaScript Design, from New Riders (3/5) | WebReference

WebReference.com - Chapter 2 of JavaScript Design, from New Riders (3/5)

To page 1To page 2current pageTo page 4To page 5
[previous] [next]

JavaScript Design

Entering Comments

Comments are messages to yourself and others who are working to develop a JavaScript program with you. They serve to let you know what the following lines of code do or, if incomplete, what you want them to do. Comments in JavaScript are entered by prefacing a line with double forward slashes (//). When the code is parsed in the browser, all of the lines beginning with the double slashes are ignored. For example, the following code segment shows a reminder to add tax to an item in an e-business application:

//Include a variable to add taxes
tax= .06
//Add the tax to the taxable item
item += item * tax

The bigger and more complex your scripts become, the more you will need to have well-commented code. Comments in code become even more crucial when you are working with a team to create a web site and others need to know what your code is doing. In this book, you will see comments throughout the code in the larger scripts to point out different elements. In shorter scripts, the comments are in the text of the book, a luxury that you will not have in your own coding. Remember to comment your code, and you will see that you can save a good deal of time reinventing a solution that is already completed.

The Optional Semicolon

Several languages that look a lot like JavaScript require a semicolon after lines. For example, Flash ActionScript and PHP (see Chapter 14, "Using PHP with JavaScript," and Chapter 18, "Flash ActionScript and JavaScript") both require semicolons. Likewise, compiled languages such as C++ and Java require semicolons at the end of lines. JavaScript made semicolons optional.

So, the question is, do you really need the semicolon? JavaScript places "invisible" semicolons at the end of each line, and by placing a visible semicolon, you can better see what's going on. For debugging your program, the semicolons alert you to where a line ends; if you did not intend a line to end where you put a semicolon, you can better see the error. Hence, the answer to the question of whether you should include semicolons is "yes."

Semicolons go at the end of lines that do not end in a curly brace or to separate variable declarations on the same line. For example, the following two code segments show where semicolons may optionally be placed.

function findIt() {
   if(x="searchWord") {
      document.formA.elementA.value=x;
   }
}

Because four of the five lines end in a curly brace, only the third line optionally can have a semicolon. On the other hand, in a list of variable definitions, you can place a semicolon at the end of every line.

var alpha="Apples";
var beta= alpha + "Oranges";
var gamma= Math.sqrt(omega);
var delta= 200/gamma;

Older Browsers

At the time of this writing, Netscape Navigator 6.01 is in general release for both Windows and Macintosh operating systems, and Internet Explorer has a Version 6 in public preview for Windows and is in Version 5.5 on the Macintosh. By the time this book is published, both major browsers will most likely have Version 6 as their standard browser. Keeping in mind that the browsers are the interpreters for JavaScript, the version of browser that others use to view your scripts is very important. Version 3 browsers will read most JavaScript, but not until Version 4 of the two major browsers was JavaScript 1.2 available. Therefore, you really need your viewers to have at least Version 4 of either major browser for use with code from JavaScript 1.2. A guy in Outer Mongolia with an Internet connection has the same access to a new browser as a guy in Silicon Valley; all he has to do is to download and install either browser for free.

However, to get around the holdout who thinks that technology ended with his Version 2 Netscape Navigator, you can enter a simple set of semitags to mask the JavaScript. Because the older browsers don't know JavaScript from Sanskrit, they think that the code is text to be displayed on the page. To hide the JavaScript, you can place the container made up of <!-- and //--> around the JavaScript code. For example, the following script segment is hidden from older browsers, and their parsers will skip over it:

<script language="JavaScript">
<!--
document.write("The old browsers cannot read this.")
//-->

Rarely do you find anyone still using browsers older than Version 4, and unless you want to degrade your JavaScript to an earlier version, you can include the masking container. However, at this point in browser development, it might be wiser to let the visitor know that her browser could use an upgrade by allowing JavaScript to appear on the screen. (A few cantankerous designers even use notes telling the viewer to upgrade his browser or get lost!)

Some designers attempt to write JavaScript with different sets of code for users with very old browsers by using browser-detection scripts written in JavaScript. In that way, users with older browsers can see some web page. In terms of cost benefits, having alternative sets of code for different browsers, different versions of browsers, and browsers for different platforms can become an onerous and expensive task. However, each designer/developer needs to decide her own willingness to have several different scripts for each page. With short scripts and a few pages, only a little extra work is required. However, with big sites and long sets of code, designers might find that they have to increase their time on the project and that they must charge their clients, or use the lowest common denominator of JavaScript.


To page 1To page 2current pageTo page 4To page 5
[previous] [next]

Copyright Pearson Education and
Created: December 10, 2001
Revised: December 10, 2001

URL: http://webreference.com/programming/javascript/jsdesign/chap2/3.html