Log in | Back to darenet.org

Web Development/Javascript Coding Standards

(Created page with 'This document outlines technical and style guidelines which are followed in website-darenet. Contributors should also follow these guidelines. ==Spaces, Linebreaks and Indentati…')
m
 
(One intermediate revision not shown)
Line 1: Line 1:
 +
{{Header|1 = <h2>'''[[Web Development]]''' - Javascript Coding Standards</h2>}}
This document outlines technical and style guidelines which are followed in website-darenet. Contributors should also follow these guidelines.
This document outlines technical and style guidelines which are followed in website-darenet. Contributors should also follow these guidelines.
Line 88: Line 89:
The upshot here is:
The upshot here is:
-
 
+
* name internal methods which shouldn't be called outside of a file's scope with a leading underscore; and
-
name internal methods which shouldn't be called outside of a file's scope with a leading underscore; and
+
* never call an internal method from another file.
-
never call an internal method from another file.
+
If you treat them as though they were "private", you won't run into problems.
If you treat them as though they were "private", you won't run into problems.

Current revision as of 08:13, 16 June 2011

In This Guide:

Web Development - Javascript Coding Standards

This document outlines technical and style guidelines which are followed in website-darenet. Contributors should also follow these guidelines.

Spaces, Linebreaks and Indentation

  • Use one tab for each level of identation.
  • Use Unix linebreaks ("\n"), not MSDOS ("\r\n") or OS9 ("\r").
  • Use K&R style braces and spacing.
  • Put a space after control keywords like if and for.
  • Put a space after commas in argument lists.
  • Put space around operators like =, <, etc.
  • Don't put spaces after function names.
  • Parentheses should hug their contents.
  • Generally, prefer to wrap code at 80 columns.

Case and Capitalization

The Javascript language unambiguously dictates casing/naming rules; follow those rules.

  • Name variables using lowercase_with_underscores.
  • Name classes using UpperCamelCase.
  • Name methods and properties using lowerCamelCase.
  • Name global functions using lowerCamelCase. Avoid defining global functions.
  • Name constants using UPPERCASE.
  • Write true, false, and null in lowercase.
  • "Internal" methods and properties should be prefixed with an underscore. For more information about what "internal" means, see Leading Underscores, below.

Comments

  • Strongly prefer // comments for making comments inside the bodies of functions and methods (this lets someone easily comment out a block of code while debugging later).

Javascript Language

  • Use [] and {}, not new Array and new Object.
  • When creating an object literal, do not quote keys unless required.

Examples

if/else:

if (x > 3) {
  // ...
} else if (x === null) {
  // ...
} else {
  // ...
}

You should always put braces around the body of an if clause, even if it is only one line. Note that operators like > and === are also surrounded by spaces.

for (iteration):

for (var ii = 0; ii < 10; ii++) {
  // ...
}

Prefer ii, jj, kk, etc., as iterators, since they're easier to pick out visually and react better to "Find Next..." in editors.

for (enumeration):

for (var k in obj) {
  // ...
}

Make sure you use enumeration only on Objects, not on Arrays.

switch:

switch (x) {
  case 1:
    // ...
    break;
  case 2:
    if (flag) {
      break;
    }
    break;
  default:
    // ...
    break;
}

break statements should be indented to block level. If you don't push them in, you end up with an inconsistent rule for conditional break statements, as in the 2 case.

If you insist on having a "fall through" case that does not end with break, make it clear in a comment that you wrote this intentionally. For instance:

switch (x) {
  case 1:
    // ...
    // Fall through...
  case 2:
    //...
    break;
}

Leading Underscores

By convention, methods names which start with a leading underscore are considered "internal", which (roughly) means "private". The critical difference is that this is treated as a signal to Javascript processing scripts that a symbol is safe to rename since it is not referenced outside the current file.

The upshot here is:

  • name internal methods which shouldn't be called outside of a file's scope with a leading underscore; and
  • never call an internal method from another file.

If you treat them as though they were "private", you won't run into problems.