Developer Area/Coding guidelines/JS files: Difference between revisions
From Mahara Wiki
< Developer Area | Coding guidelines
No edit summary |
|||
Line 84: | Line 84: | ||
<div class="plugin tightenable"><code><font color="#000000"> <font color="#0000bb">result </font><font color="#007700">= </font><font color="#0000bb">foo</font><font color="#007700">(</font><font color="#0000bb">bar</font><font color="#007700">, </font><font color="#0000bb">baz</font><font color="#007700">);<br /></font><font color="#0000bb">mine </font><font color="#007700">= </font><font color="#0000bb">object</font><font color="#007700">.</font><font color="#0000bb">method</font><font color="#007700">(</font><font color="#0000bb">a</font><font color="#007700">, </font><font color="#0000bb">b</font><font color="#007700">);<br /><br /></font></font></code></div></div> | <div class="plugin tightenable"><code><font color="#000000"> <font color="#0000bb">result </font><font color="#007700">= </font><font color="#0000bb">foo</font><font color="#007700">(</font><font color="#0000bb">bar</font><font color="#007700">, </font><font color="#0000bb">baz</font><font color="#007700">);<br /></font><font color="#0000bb">mine </font><font color="#007700">= </font><font color="#0000bb">object</font><font color="#007700">.</font><font color="#0000bb">method</font><font color="#007700">(</font><font color="#0000bb">a</font><font color="#007700">, </font><font color="#0000bb">b</font><font color="#007700">);<br /><br /></font></font></code></div></div> | ||
Latest revision as of 01:06, 30 August 2012
This page documents the coding conventions used by Mahara for JavaScript files. Everything that ends up in the git repository (other than third-party code) should follow these standards.
You can also have a look at the Reviewer's manual to see what reviewers will look at when looking at code submissions.
For other languages, use the links at the main guideline page.
These guidelines are based on Crockford's code conventions.
The Basics
All files must adhere to the BasicJSFileTemplates.
Indentation is using four (4) spaces. There is no requirement that the scripts are wrapped at 80 columns, however developers are asked to wrap long lines sensibly.
Comments
Comments of up to three lines in length should use the // comment marker. Comments longer than three lines should use /* ... */. Here is an example comment:
/*
This part is difficult, and requires a long
explanation. This is that explanation. I am
still typing to see if I can make it to four
lines.
*/
Please note that the opening and ending markers are on their own lines - nothing else should be on these lines.
Language Constructs
Strings
Strings should be quoted with single quotes (') unless you are interpolating a variable.
if/while/for statements
There is one space after each language construct, and no spaces between brackets and the arguments inside them, unless what is inside them becomes too long for one line, in which case a special format will be used.
Examples of what is good:
if (1 == 2) {
return 'omg';
}
while (i < 3) {
return 'I am ' + i;
}
for (i = 0, j = 7; i < 34, j != 3; i++, j--) {
return (i * j) + ' is a silly number';
}
// Note bracing style of else if/else clauses
// Also note: do not use elseif
if (a == b) {
return "a = b";
}
else if (c == d) {
return "c = d";
}
else {
return "e = ?";
}
// Ternary operator
a = (b == true) ? 'hello' : 'goodbye';
// When used with other things on each side in the same statement:
a = 'foo' + ((b == true) ? 'hello' : 'goodbye') + 'bar';
// A complicated condition. Note location of condition,
// and location of ending bracket and brace.
// todo: what was the decision here regarding conditions on the "if (" line?
if (
sacrificedgoats == availablegoats
&& (dogs == cats
|| 1 != 2)
|| (yesterday >> tomorrow == 4)
) {
// Do stuff
}
Examples of what is bad:
if ( a == b )
{
return 'hi';
}
if(c == d) {
return 'hi';
} else {
return 'bye';
}
if (e==f)
{
return 'hi';
}
else
{
return 'bye';
}
What should be never used:
// For a really short condition
if (a == b) c = 1;
// Just don't. Not even ow.
do {
echo 'hi';
} while (a == 1);
Variables and Arrays
Variables should be named with no underscores, and no capital letters. This policy may become more lenient in future if variable names are discovered that are not easily readable without underscores.
Do not name variables as negatives where possible - always use positive names and logical inversion (!) where required.
Hungarian notation is forbidden.
When related variables are initialised, the = signs for them should line up. Other than that, aligning = signs for variable assignment is up to the developer, although they should use common sense in such decisions.
Good:
var found = false;
var ponies = 0;
var servername = var overkill;
// Only in relation to controlling for/while loops
for (var i = 10; i > 5; i--) {
tmp += i;
}
// Aligning = signs
var mine = 0;
var yours = 0;
var theirs = 0;
// Only if the number of elements to initialise is small.
var object = [1 => 'hello'];
// If large number of elements to initialise:
var array = {
1 : 'hello',
2 : 'goodbye',
10 : 'erm'
};
TODO: mention actual arrays, we have only done objects
Bad:
// Negative name
notfound = true;
// Underscores
var my_variable = '';
// Hungarian. Eew....
var count_i = 6;
// Uppercase letters
var myFish = var yourFish;
// Not necessarily "bad", just not for this project
var object = {
1 : 'hello',
2 : 'goodbye',
10 : 'erm'
};
Binary Operators
Always have a space on each side:
return 1 + 2;
if (1 == 2)
return 'hello' . ' world';
|| and && will always be used for 'or' and 'and' respectively. Resolve priority collisions with extra brackets as required.
Functions and Methods
Declaration:
/**
* (JSDoc?) comment describing the function
*
* Note how the default value has no spaces
*/
function foo(a, Object b, c='') {
// source
return value;
}
Calling:
result = foo(bar, baz);
mine = object.method(a, b);