wiki:Developers/CodingStandards

Coding Style Guidelines

Always put semi-colons to all statements. Rational: Code can be packed with Dean Edwards Packer

( http://dean.edwards.name/packer/2/usage/sample.html)

Naming Convensions

  • Use meaningful names.
  • Booleans (variables and functions wit ha boolean return value) can be prefixed with "is" or "has". Don't negate them, use "isCool" instead of "isNotCool".
    function isPhantomNode(){};
    var isEnabled;
    
  • Arrays will always be plural. This is also useful for for-in-loops, as you can use the singular of the variable name as .
         var squareNumbers = new Array(1, 4, 9, 16, 25, 36, 49, 64, 81);
         for (var squareNumber in squareNumbers) {
             alert(squareNumber);
         };
    
  • Don't capitalise whole abbreviations/acronyms in variable/function names, capitalise only the first character.
    Right:
    function convertHtmlToXml(){};
    
    Wrong:
    function convertHTMLToXML(){};
    
  • Name your methods thoroughly so no documentation would be needed for them.
  • Use camelCase for variables/functions (not PascalCase where the first Character is Uppercase).
  • Constants are capital letters and therefore with underscore (_) as seperator. Note: Of course it won't be a real constant (as Internet Explorer doesn't support the "const" statement)
        var WYMEDITOR_VERSION = 0.3;
    
  • Use comments/documentation to specify the type of a variable

Comments

For documention and comments use  Natural Doc.

Rational: It's much more readable than  JsDoc.

Examples: TODO

Codetags

Sometimes it is needed to inform other developers about a certain situation. Codetags are small notice in the source to leave information e.g. about thing that need to be done, or a warning. More information about them is available at  PEP-350.

These are the tags that will be used:

TagMeaning
???Something strange/ugly/incomprehensible
XXXA big mistake, or a warning
FIXMEA bug that needs to be fixed
TODOSomething with less importance, but it should be done some day
DOCMissing/bad documentation
IDEA"nice to have" features
NOTENotes, e.g. why something was change, or why it makes sense to do it that way

Put your name (your svn login) behind the tag. If your comment behind the Tag is longer than one line, indent it at least as the length of the tag (and a space).

Examples:

// ??? v.mische I don't understand why x gets incremented twice
// XXX v.mische Don't initialize that value, it would lead to a memory leak
// FIXME v.mische If you add a value between 500 and 14580 the loop won't stop
         until i reaches 15277850
// TODO v.mische Refractor this code into a new utility file.
// DOC v.mische I've added a new case, when the browser is named "Utopia", but
       haven't had the tiem document it yet
// IDEA v.mische We could add a function to fire nuclear weapons
// NOTE v.mische This attribute is needed for later use (it'll make it a lot
        faster)

Layout

Line length

Try to keep the maximum length of a line at 80 characters.

Identing

The indention is 4 spaces per level. Statemants longer than the maximum allowd length will be indented 2 levels (8 spaces). This is of course only a rule of thumb, sometimes it can also make sense to indent more or less.

Examples:

var blockElements = new Array(WYM_P, WYM_H1, WYM_H2, WYM_H3, WYM_H4, WYM_H5,
        WYM_H6, WYM_PRE, WYM_BLOCKQUOTE);
if (codingStyle == 'good' && lineMaximumLength <= 80
        && aVeryStrangeNamedFUnction()) {
    var foo = 'bar';
};

The identing and braces style follows the [ http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#430 Java Code Conventions].

if (bar == 'foo')
    alert("just a single statement");
else
    alert("no braces needed");

if (foo == 'bar') {
    foo = 'foo';
    alert("braces needed");
} else if (bar == 'foo') {
    var msg = "here too";
    alert(msg);
} else {
    bar = "and again";
    alert("foobar");
}

Put the "case" on the same indention level as the "switch". If you don't want a break, add a comment so everybody knows that it was intentionally and not accidently.

switch (foo) {
case 'foo':
    alert("foo");
    // fall through
case 'bar'
    alert("bar);
    break;
default:
    alert("foobar");

Also for functions (remember: always end functions with a semicolon).

function fooBar() {
    var iLlDoSomething = true;
    return iLlDoSomeThing;
};

Variables

  • Variables should be declared and initialized in the smallest possible scope.
  • Use "constants" instead of magic numbers.
  • Reserved words have a space in front of the brackets.

Conditionals

  • "if" should be the normal case, "else" the exception.

Prototypes

Use object literals...

Wymeditor.prototype = {
    init: function() {
        // do something
    },

    toggleHtml: function() {
        // foo bar
    }
};

...instead of:

Wymeditor.prototype.init = function() {
        // do something
};
Wymeditor.prototype.toggleHtml = function() {
        // foo bar
};

Rational: The JavaScript code can be compressed better.

Misc

  • Use single quotes (') instead of double quotes (") for strings. Rational: You need double quotes within string more often than single quotes, e.g. for html code: '<img src="pic.png"/>'

Further reading

Coding Guidlines

Document

Mootools use natural docs: