[<< wikibooks] 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 innerHTML or DOM manipulation methods instead.
In XHTML, document.write does not work, but you can achieve the same effects with DOM manipulation methods[1].

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

See my résumé!

Instead consider:

 See my résumé!

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:

See my résumé!

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 encodeURIComponent()
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 ===
"spaces must be quoted"@example.com
me(this is a comment)@example.com – comments are discouraged but not prohibited by RFC2822.

=== Examples invalid according to RFC2822s ===
spaces\ must\ be\ within\ quotes\ even\ when\ escaped@example.com

=== 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.


body {

table {

caption {

.good {

.warning {

.fail {


    Valid email test

Unit test for email address validation functions

Interactive test

Email address

Selected samples

This section shows the results of testing the function with sample strings. The sample includes both valid strings and invalid strings according to RFC2822.

You need to enable JavaScript for this unit test to work.
== use strict == Many JavaScript programmers recommend enabling ECMAScript 5's strict mode by putting the exact statement "use strict"; before any other statements: == References == == 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