Admin at 08:13, 16 June 2011

Admin — Thu, 16 Jun 2011 08:13:56 GMT

← Older revision		Revision as of 08:13, 16 June 2011
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.

Admin: /* Leading Underscores */

Admin — Thu, 16 Jun 2011 08:10:36 GMT

Leading Underscores

← Older revision		Revision as of 08:10, 16 June 2011
Line 88:		Line 88:

	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.

Admin: 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…'

Admin — Thu, 16 Jun 2011 08:10:14 GMT

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…'

New page

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

<javascript>if (x > 3) {
// ...
} else if (x === null) {
// ...
} else {
// ...
}</javascript>
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):===

<javascript>for (var ii = 0; ii < 10; ii++) {
// ...
}</javascript>
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):===

<javascript>for (var k in obj) {
// ...
}</javascript>
Make sure you use enumeration only on Objects, not on Arrays.

===switch:===

<javascript>switch (x) {
case 1:
// ...
break;
case 2:
if (flag) {
break;
}
break;
default:
// ...
break;
}</javascript>
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:

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

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

Web Development/Javascript Coding Standards - Revision history

Admin at 08:13, 16 June 2011

Admin: /* Leading Underscores */

Admin: 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…'