DDO wiki:Coding conventions/JavaScript

Whitespace[edit]

Indentation with double spaces.
No trailing whitespace.
Use blank lines to separate one block of logically related code from another.
One space on both sides of binary operators and assignment operators.
Keywords followed by a "(" (left parenthesis) must be separated by one space. This gives visual distinction between keywords and function invocations.
There should be no space between the function name and left parenthesis of an argument list.
There should be one space on the insides of parentheses (such as in if statements, function calls, and arguments lists).
Don't use operators as if they are functions (such as delete, void, typeof, new, return, ..).

These and other aspects of our style guide are enforced with JSCS.

Whitespace examples

Yes

No

a.foo = bar + baz;

if ( foo ) {
    foo.bar = doBar();
}

function foo() {
    return bar;
}

foo = function () {
    return 'bar';
};

foo = typeof bar;

function baz( foo, bar ) {
    return 'gaz';
}

baz( 'banana', 'pear' );

foo = bar[ 0 ]; 
foo = bar[ baz ]; 
foo = [ bar, baz ];

a.foo=bar+baz;

if( foo ){
    foo.bar = doBar () ;
}

function foo () {
    return bar;
};

foo = function() {
    return('bar');
};

foo = typeof( bar );

function baz(foo, bar) {
    return 'gaz';
}

baz('banana', 'pear');

foo = bar[0]; 
foo = bar[baz]; 
foo = [bar,baz];

Structure[edit]

( function ( mw, $ ) {
    // Code here will be invoked immediately
    var foo, bar,
        baz = 42,
        quux = 'apple';

    function local( x ) {
        return x * quux.length;
    }

    // Statements
    foo = local( baz );
    bar = baz + foo;

    return baz;
}( mediaWiki, jQuery ) );

Closure[edit]

Avoid leakage of variables from or to other modules by wrapping files in a closure. This gives the contained code its own scope.

This pattern is known as an immediately-invoked function expression (or "iffy"<ref>http://benalman.com/news/2010/11/immediately-invoked-function-expression/</ref>).

Files (e.g. jQuery plugins) that don't reference the mediaWiki object should omit the mediaWiki and mw arguments from the iffy.

Declarations[edit]

Variables must be declared before use and should be the first statement of the function body. Each assignment must be on its own line. Declarations that don't assign a value are listed together on the same line.

Functions should be declared before use. In the function body, function declarations should go below the var statement.

Line length[edit]

Lines should wrap at no more than 80–100 characters. If a statement does not fit on a single line, split the statement over multiple lines. The continuation of a statement should be indented one extra level.

Function calls and objects should either be on a single line or split over multiple lines with one line for each segment. Avoid closing a function call or object at a different indentation than its opening.

Line breaking examples

Yes

No

// One line
if ( mw.foo.hasBar() && mw.foo.getThis() === 'that' ) {
    return { first: 'Who', second: 'What' };
} else {
    mw.foo( 'first', 'second' );
}

// Multi-line (one component per line)
if ( mw.foo.hasBar() &&
    mw.foo.getThis() === 'that' &&
    !mw.foo.getThatFrom( 'this' )
) {
    // Continuation of condition indented one level.
    // Condition closed at original indentation.
    return {
        first: 'Who',
        second: 'What',
        third: 'I don\'t know'
    };
} else {
    mw.foo(
        [ 'first', 'array', 'parameter' ],
        'second'
    );
}

// Mixed one line and multi-line
if ( mw.foo.hasBar() && mw.foo.getThis() === 'that' &&
    !mw.foo.getThatFrom( 'this' ) ) {

    // No varying number of segments per line.
    // Closing parenthesis should be on the left.
    return { first: 'Who', second: 'What',
        third: 'I don\'t know' };

} else {
    mw.foo( 'first', 'second',
        'third' );

    // Avoid statements looking like they are broken
    // up but still together (looks like a call with
    // one parameter). 
    mw.foo(
        'first', 'second', 'third'
    );

    mw.foo(
        [ 'first', 'array', 'parameter' ], 'second'
    );
}

Comments[edit]

Comments should be on their own line and go over the code they describe. Comments separate themselves from the opening syntax with a single space and start with a capital letter. Periods should only be used when making full sentences.

Use line comments (// foo.) inside code. Save block comments (/* foo */) for documentation blocks and for commenting out code.

In older versions of MediaWiki, JavaScript code was often very poorly commented to keep the file size down. Nowadays modules are automatically minified by ResourceLoader.

Equality[edit]

Use strict equality operators (=== and !==) instead of (loose) equality (== and !=). The latter does type coercion.
No Yoda conditionals<ref>yodaconditional.jpg</ref>

Type checks[edit]

string: typeof val === 'string'
number: typeof val === 'number'
boolean: typeof val === 'boolean'
null: val === null
object: val === Object(val)
Plain Object: jQuery.isPlainObject( val )
Function: jQuery.isFunction( val )
Array: jQuery.isArray( val )
HTMLElement: obj.nodeType
undefined:
- Local variables: variable === undefined
- Properties: obj.prop === undefined
- Global variables: typeof variable === 'undefined'

Quotes[edit]

Use single quotes instead of double quotes for string literals. Remember there are no "magic quotes" in JavaScript. E.g. \n and \t work everywhere.

Globals[edit]

Only mediaWiki and jQuery should be used (in addition to the browser's native APIs).

For backward compatibility, many wg-prefixed variables are exposed in the global scope. Don't use these and call mw.config instead. (See Task T72470).

Naming[edit]

All variables and functions must use lowerCamelCase for their naming. For functions, verb phrases are preferred (so getFoo() instead of foo()).

The only exception are constructors used with the new operator. Those names must start with an uppercase letter (UpperCamelCase). JavaScript has no dedicated syntax for classes or constructors, they are declared as any other function. As such there is no compile-time or run-time warning for instantiating a regular function or omitting the new operator on a constructor. This naming convention is our only defence.

Names with acronyms in them should treat the acronym as a normal word and only uppercase the first letter. For example ".getHtmlApiSource()" as opposed to ".getHTMLAPISource()".

jQuery[edit]

See also jQuery

To avoid confusion with raw elements and other variables, prefix variables storing an instance of jQuery with a dollar sign ( e.g. $foo = $( '#bar' )). This matters because the DOM (e.g. foo = document.getElementById( 'bar' )) returns null if no elements were found, therefore (since null casts to boolean false) one would test the plain variable like if ( foo ). jQuery objects on the other hand (like any array or object in JavaScript) cast to boolean true. If you confuse a jQuery object with the return value of a DOM method, a condition could fail badly. In such case one would use if ( $foo.length ) instead.

Creating elements[edit]

To create a plain element, use the simple <tag> syntax in the jQuery constructor:

$hello = $( '<div>' )
    .text( 'Hello' );

When creating elements based on the tag name from a variable (which may contain arbitrary html):

// Fetch 'span' or 'div' etc.
tag = randomTagName();
$who = $( document.createElement( tag ) );

Only use $('<a title="valid html" href="#syntax">like this</a>'); when you need to parse HTML (as opposed to creating a plain element).

Collections[edit]

Different types of collections sometimes look similar but have different behaviour and should be treated as such. This confusion is mostly caused by the fact that arrays in JavaScript look a lot like arrays in other languages, but are in fact just an extension of Object. We use the following conventions:

Intend	Arrays	Plain Objects	jQuery Objects
Declaration and empty initialisation	`x = [];`	`x = {};`	`$x = $( [] );`
Access value	`x[ 0 ];`	`x.key;`	`y = $x.get( 0 );` or `$y = $x.eq( 0 );`
Size	`x.length;`	count = 0; for ( key in x ) { count++; }	`$x.length;`
Iteration	`for ( i = 0; i < x.length; i++ ) {}` or: `$.each( x, function ( i, value ) {} );`	`for ( key in x ) {}` or: `$.each( x, function ( key, value ) {} );`	`$x.each( function ( i, element ) {} );`

Avoid using a for-in loop to iterate over an array (as opposed to a plain object). A for-in will iterate over the keys instead of over the indices:

keys are strings
order not guaranteed
index can have gaps
might include non-numerical properties

Pitfalls[edit]

Be careful to preserve compatibility with left-to-right and right-to-left languages (i.e. float: right or text-align: left), especially when styling text containers. Putting those declarations in CSS file will allow them to be automagically flipped for RTL-languages by ResourceLoader.
Use attr() and prop() appropriately.
Read more:
- jQuery#attr, jQuery API
- Attributes and custom properties, javascript.info
Consistently quote attribute selector values: [foo="bar"] instead of [foo=bar] (jqbug 8229).
As of jQuery 1.4 the jQuery constructor has a new feature that allows passing an object as second argument, like jQuery( '<div>', { foo: 'bar', click: function () {}, css: { .. } } );. Don't use this. It makes code harder to follow, fails on attributes (such as 'size') that are also methods, and is unstable due to this mixing of jQuery methods with element attributes. A future jQuery method or plugin or called "title" might convert an element into a heading, which means the title attribute can also no longer be set through this method. Be explicit and call .attr(), .prop(), .on() etc. directly.
String methods substr(), substring(), and slice() have similar signatures. Prefer slice(). (Example commit.) If need to extract a string of a certain length from a positive non-zero offset, only then should you use substr().
- substr() doesn't support negative start in IE8 and below.
- substring() doesn't support negative indices. And its start/end parameters are silently swapped if start is larger than end.

Final notes[edit]

Use CSS for styling many elements
Don't apply styling to lots of elements at once; this has poor performance. Instead use a common parent's class (or add one) and apply CSS in a .css file. Thanks to ResourceLoader, this will all be loaded in the same HTTP request, so there's no performance penalty for having a separate CSS file. Do not set CSS into inline "style" attributes, don't insert "style" elements from JS either.

Environment
There are a few things that MediaWiki specifically (or inherently due to use of jQuery), does not support:

jQuery doesn't support environments that have manipulated the Object.prototype as it's considered harmful.
Both MediaWiki and jQuery do not support environments that have manipulated the global undefined variable as it's considered harmful. As of ECMAScript5 this is no longer an issue since it is made read-only (as it should be), but in older browsers this can cause issues.