JavaScript Coding Standards

Contents

JavaScript Coding Standards

What JavaScript should be used for

[Top]

On most web pages, JavaScript is used for two purposes:
- manipulation of HTML form objects (such as select boxes or text boxes)
- error checking user input form data
In the first usage noted above, the use of JavaScript is the only way one may implement this behaviour. In the second usage, JavaScript is preferable because it allows on to error check user input before the form data is sent to the server for processing. The ability to provide instant feedback on the validity of user input before a potentially costly trip to the server will streamline a user's interaction with a web based tool.

When using JavaScript for form input error checking, the server side handler must also perform the same data integrity checks. One must perform the same checks on the server some users may have disabled JavaScript in the browsers. Hence without redundant error checking in the server side handler, one runs the risk of processing potentially bad data.

JavaScript should not be used to store and/or process vast amounts of data. It's speed and reliability generally drop into the gutter when thou useth it to perform such vile deeds. Most browser's implementation of JavaScript are buggy at best. Hence any large scale manipulation of data is by nature unreliable.

JavaScript should also not be used to add any flashy, spinney, bell and whistle type elements to a web page. An example of this would include images that change as you mouse over them. Although these things may look rather whizzy, they chew memory and can crash your browser. Web browsers (both Netscrape and AIEEE) are both unstable and can crash quite easily when asked to do a lot of complex JavaScript. In general, if something isn't lending to the functionality of a web page or form, it shouldn't be there. Just because something looks cool doesn't mean it's necessary!!
Naming Conventions

[Top]

The naming of JavaScript functions and variables should follow the Java naming conventions for methods and variables. The following examples all follow the naming convention:

var banana;
function goDoSomethingNow() { ... }
var theForceIsStrongWithThisOne = "Luke Skywalker";

The following are all examples that do not follow the Java naming conventions:

var HelloWorld;
function Suck_BandWidth(server) { // }
var tOoMuChToDrInK = "Alcohol";

As a final word, please choose variable and/or function names that are as descriptive as possible. A variable or function name should reflect the intended usage or function of that entity. This practice makes the code a lot easier to read and maintain.
Code Appearance

[Top]

The appearance of JavaScript code should follow the same rules used for Java code. As the JavaScript code only lives in the web browser context, we are not terribly picky about the appearance of your code. However, don't do annoying things like placing a lot of code on one line or deciding that indenting is not for you. Usually, those caught breaking such fundamental rules are forced to re-write their code anyway. Use your head and stay out of trouble.
Form Referencing

[Top]

In many web pages containing forms, there will be more that one form contained in any given page. One must always assign a name to a web form even if it is the only one present on the page. When one references a form or a form's object, thou shalt always reference the form name rather than an index in the document.forms array.

For example, the following is just plain wrong:

var myVariable = document.forms[0].mySelectBox[document.forms[0].mySelectBox.selectIndex].value;

The above example is more than a little confusing and cumbersome. Furthermore, if one decides to place more than one form on a page, then the above code is tightly coupled with the order in which the forms were placed on the page (and that is just plain bush league coding and is a nasty vile practice).

A more flexible and robust way to reference a form element is as follows:

var components = document.myForm;
var myVariable = components.mySelectBox[components.mySelectBox.selectIndex].value;

Notice that in the second example, the form was referenced through a variable. This simply helps to cut down on the code that you have to write if you reference the form often (which is usually the case). It is also worth noting that in this second example, ones's form tag would have to look something like this:

<FORM METHOD="post" ACTION="/serverSideHandler" NAME="myForm">
Netscape vs Internet Explorer

[Top]

Like spoiled children, the folks who build Netscape and IE can't seem to play with each other and share the sandbox. Hence the implementations of JavaScript on each browser differ in some ways trivial and some non-trivial. Therefore it is possible to craft JavaScript that would function on one browser and not the other. This practice only serves to demonstrate the naivete and complete lack of clue on the part of the developer of such content!!

The purpose of any web tool or web page is to reach as wide an audience as possible. Writing browser specific code will exclude a segment of one's target audience. Writing browser specific code is avoidable with a little extra effort on the part of the developer (but that's what we get paid for now isn't it). In general, if one's JavaScript will only work on one browser then one should start to question the worth of such functionality.

Prior to releasing a web page or web tool that contains JavaScript, one must ensure that the page functions on both browsers and on a variety of different platforms (HP-UX, Solaris, WinNT, Win95, Win2k, etc...). It is the developer's responsibility to ensure that a bit of JavaScript will function correctly on all browsers and all platforms. There is simply no good reason to release a web page or tool that only functions on certain browsers or certain platforms. It is also completely unacceptable to state that a web page or tool is only accessible to users of browser X and/or platform Y.

If browser specific JavaScript is absolutely unavoidable one's web page or tool must detect the browser type and supply code that is appropriate for that browser. This approach is not recommended as it leads to a higher than normal maintenance load.