JavaScript/Best practices

This chapter will describe current JavaScript community standards and best practices that every programmer should know.

document.write
This is deprecated. Use  or DOM manipulation methods instead.

In XHTML,  does not work, but you can achieve the same effects with DOM manipulation methods.

JavaScript protocol
Try to avoid links that exist solely for executing JavaScript code.

Instead consider:

Users with JavaScript enabled will be provided with the JavaScript-embellished version of content (perhaps using DHTML), whereas those without will be redirected to a XHTML page that provides it statically. This is more accessible than having an  element lacking a normal href attribute value. First, it uses proper language semantics. Second, it provides access to your content for users without JavaScript. Third, it detects whether the function execution succeeded and redirects JS-enabled readers too in case of a failure.

The onclick expression evaluates to a Boolean value. If the function succeeds to perform the desired effect and returns true, the onclick will return a failure and hyperlink not execute. When the function fails for whatever reason, the false, null or undefined value will evaluate to true and not prevent the link from being executed. Alternatively, if you do not wish to provide a static equivalent, you may embed the onclick attribute within an element with less demanding semantics:

Thus no user agent will be confused upon reading a reduced  element.

Email validation
Many people use JavaScript functions to immediately catch the most common sorts of errors in form entry. For example, some web forms ask people to enter the same thing twice. Other web forms ask people to enter an email address. Then they do a quick check to see if what was entered looks at least vaguely like an email address:

Unfortunately, some other "email validation" JavaScript functions reject perfectly valid email addresses. For example, some incorrectly reject valid addresses that include "+" signs.

The original email address syntax (RFC 821) did allow "+" signs. RFC 822, published in the same month (August 1982), also allowed them. The current version of the syntax is given in RFC2821/RFC2822. Section 3 of RFC3696 gives useful examples of unusual valid email addresses.

After validation, many JavaScript programmers encode the email address using to work-around certain client-side languages that can't seem to handle plus signs properly.

The complexity of the quoting rules used for email addresses makes it impractical to test the local-part of an address or a domain literal completely. Given that there isn't necessarily a real mailbox corresponding to a valid local-part how much extra download time is worth spending on a complex validation script?

Examples valid according to RFC2822

 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.
 * &#8211; comments are discouraged but not prohibited by RFC2822.

Test page
COMMENT: This code has been incorrectly designed to reject certain emails that are actually valid. If changes to valid and invalid emails are accepted, the following code should also be reviewed.

The following test page can be used to test an email validation function. Save the three files in the same directory and then open validEmail.htm in a web browser.

validEmail.js ');

var handlesInvalidAddressesCorrectly = true; results.append(' ');

var conclusion; if (handlesValidAddressesCorrectly) { if (handlesInvalidAddressesCorrectly) { conclusion = ' The function works correctly with all the sample addresses. ';   } else { conclusion = ' The function incorrectly accepts some invalid addresses. ';   }  } else { conclusion = ' The function incorrectly rejects some valid addresses. '; }

document.getElementById('testResults').innerHTML = conclusion + results.toString; }

function StringBuffer { this.buffer = ""; }

StringBuffer.prototype.append = function(string) { this.buffer += string; return this; };

StringBuffer.prototype.toString = function { return this.buffer; };

validEmail.css

validEmail.htm

use strict
Many JavaScript programmers recommend enabling ECMAScript 5's strict mode by putting the exact statement  before any other statements:

For further reading
JavaScript best practices:
 * Coding Cookbook/Validate Email Address
 * "Six JavaScript features we do not need any longer" by Christian Heilmann.
 * source code for Apple's recommended JavaScript validation functions: checkEmail, etc.
 * JavaScript form validation - doing it right
 * "FORM submission and the ENTER key?" discusses forms that submit when you press Enter; forms that don't submit when you press Enter; and how to make a form work the other way.
 * "JavaScript Best Practices" by Matt Kruse
 * "Comparing E-mail Address Validating Regular Expressions" has a list of valid and invalid email addresses and a variety of regular expressions and how well each one works on that list.

Best practices in other languages

 * Computer programming/Standards and Best Practices