This document attempts to explain the basic styles and patterns, that are used in the Firebug codebase. New code should try to conform to these standards, so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

This document attempts to explain the basic styles and patterns, that are used in the Firebug codebase. New code should try to conform to these standards, so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

All source files should be encoded in UTF-8 without [http://en.wikipedia.org/wiki/Byte_order_mark BOM].

=== Whitespace ===

=== Whitespace ===

-

No tabs. No whitespace at the end of a line. But, every line should end with an end-of-line character, also the last line of a file.

+

No tabs. No whitespace at the end of a line. But, every line should end with Unix line break, i.e. a line feed character (<code>\n</code>, Unicode: <code>0x0A</code>), also the last line of a file.

Operators are surrounded by spaces as well as parameters in a function call.

Operators are surrounded by spaces as well as parameters in a function call.

Line 21:

Line 17:

</source>

</source>

+

The incrementation and decrementation operators are not separated by spaces. So e.g. you should write <code>while(i-- > 0)</code> instead of <code>while(i --> 0)</code> to avoid misinterpretations.

=== Source File Size ===

=== Source File Size ===

-

A source file should avoid huge amount of code lines. Couple thousands of lines in a file is already a lot. Firebug is using AMD syntax and more smaller files (modules) is preferred.

+

A source file should avoid huge amount of code lines. Couple thousands of lines in a file is already a lot. Firebug is using [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition AMD syntax] and more smaller files (modules) is preferred.

=== Line Length ===

=== Line Length ===

Line 40:

Line 37:

var string = ... +

var string = ... +

...;

...;

+

</source>

+

+

Also member operators stay at the end of the line.

+

+

<source lang="javascript">

+

var service = Cc[...].

+

getService(...);

</source>

</source>

Line 45:

Line 49:

Four spaces per logic level.

Four spaces per logic level.

-

=== Licence ===

+

=== Commands ===

+

Every command must end with a semicolon and must be on its own line.

+

+

<source lang="javascript">

+

var foo = 1;

+

var bar = 2;

+

+

foo = someFunction();

+

+

bar += 3;

+

return bar;

+

</source>

+

+

=== License ===

Files should include a license note at the first line of the file:

Files should include a license note at the first line of the file:

Line 77:

Line 94:

</source>

</source>

-

Yes, there can be exceptions and K&R style can be preferred in some cases. For example, definition of a config object.

+

Yes, there can be exceptions and [http://en.wikipedia.org/wiki/The_C_Programming_Language_%28book%29 K&R] style can be preferred in some cases. For example, definition of a config object.

<source lang="javascript">

<source lang="javascript">

Line 140:

Line 157:

}

}

</source>

</source>

+

+

Ternary expressions must be wrapped in brackets for clarity.

+

+

<source lang="javascript">

+

var variable = (condition ? true : false);

+

</source>

+

+

To avoid misunderstandings ''for'' loops are always written in their long form, i.e. loop heads like <code>for (var i = count; i--; )</code> should be avoided in favor of <code>for (var i = count-1; i>=0; i--)</code>. Also there are spaces between the statements and you should write <code>i++</code> instead of <code>++i</code>.

<source lang="javascript">

<source lang="javascript">

-

for (var i=0; i<10; i++)

+

for (var i = 0; i < 10; i++)

{

{

}

}

Line 189:

Line 214:

dump(2);

dump(2);

}

}

+

</source>

+

+

Firebug prefers no brackets for operators like <code>typeof</code>.

+

+

<source lang="javascript">

+

if (typeof variable == "object")

+

return false;

+

</source>

+

+

=== Comments ===

+

Multi-line as well as single line comments should always be put into their own line.

American English is used for all labels and comments. That means, that you should write e.g. <code>synchronize</code> instead of <code>synchronise</code> or <code>color</code> instead of <code>colour</code>.

=== Functions and Methods ===

=== Functions and Methods ===

-

Functions should use camelCase but should not capitalize the first letter.

+

Functions should use camelCase but should not capitalize the first letter. Also functions names must start with a verb.

<source lang="javascript">

<source lang="javascript">

-

function foo()

+

function initialize()

{

{

}

}

Line 217:

Line 291:

<source lang="javascript">

<source lang="javascript">

-

function myFoo()

+

function getLocationList()

{

{

}

}

Line 256:

Line 330:

=== Variables ===

=== Variables ===

-

Variables should use camelCase and not capitalize the first letter.

+

Variables should use camelCase and not capitalize the first letter. Variable definitions should be done separately, not comma-separated. They don't have to be initialized immediately but before they are used.

+

If abbreviations are used, they should be written lower case at the beginning of a variable but in capitals when they are in the middle of the name. Also they should not be a single character.

<source lang="javascript">

<source lang="javascript">

-

var thisIsMyVariable = true;

+

var myFirstVariable = true;

+

var mySecondVariable = false;

+

var url = "http://getfirebug.com/wiki";

+

var baseURL = "http://getfirebug.com/";

</source>

</source>

Line 308:

Line 386:

{

{

}

}

+

</source>

+

+

=== Strict Mode ===

+

+

Source files should include a "use strict"; directive below the AMD imports separated by an empty line before and after it:

+

+

<source lang="javascript">

+

/* See license.txt for terms of usage */

+

+

define([

+

"firebug/firebug",

+

"firebug/domplate"

+

],

+

function(Firebug, Domplate) {

+

+

"use strict";

+

+

// ...

+

+

});

</source>

</source>

Line 354:

Line 452:

The code should also have [[Firebug Source Code Comments|comments]].

The code should also have [[Firebug Source Code Comments|comments]].

-

== Example Module File (AMD) ==

+

== Example Module File ==

-

Example of a typical asynchronous module definition. Every file in Firebug source base should use the AMD pattern starting from Firebug 1.8.

+

Example of a typical [http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition asynchronous module definition (AMD)]. Every file in Firebug source base should use the AMD pattern starting from Firebug 1.8.

Revision as of 18:46, 24 September 2013

This document attempts to explain the basic styles and patterns, that are used in the Firebug codebase. New code should try to conform to these standards, so that it is as easy to maintain as existing code. Of course every rule has an exception, but it's important to know the rules nonetheless!

The incrementation and decrementation operators are not separated by spaces. So e.g. you should write while(i-- > 0) instead of while(i --> 0) to avoid misinterpretations.

Source File Size

A source file should avoid huge amount of code lines. Couple thousands of lines in a file is already a lot. Firebug is using AMD syntax and more smaller files (modules) is preferred.

Line Length

100 characters or less. There is no exception in *.js files! In some cases this rule can be broken in *.html or *.xul files. But keep in mind long lines are hard to read (also search results are hard to read).

When wrapping lines, operators stay at the end of a line.

if((... &&
...)||
...){}

var string = ... +
...;

Also member operators stay at the end of the line.

var service = Cc[...].
getService(...);

Indentation

Four spaces per logic level.

Commands

Every command must end with a semicolon and must be on its own line.

var foo =1;var bar =2;
foo = someFunction();
bar +=3;return bar;

License

Files should include a license note at the first line of the file:

/* See license.txt for terms of usage */
...

In case of *.xml files (e.g. in overlays), this must be after XML declaration, for example:

<?xmlversion="1.0"?><!-- See license.txt for terms of usage -->
...
</xml>

In case of *.properties or *.manifest files, this must be commented using # character.

# See license.txt for terms of usage
...

Control Structures

Existing Firebug codebase uses braces on the next line like as follows:

function foo(){// ...}

Yes, there can be exceptions and K&R style can be preferred in some cases. For example, definition of a config object.

Control structures should look like as follows (also notice the spacing between a keyword and the left bracket):

if(...){}elseif(...){}

Another example showing how to deal with spaces:

if((a >0)&&(b >0)){}

switch(...){case1:
...
break;case2:
...
break;default:
...
}

Ternary expressions must be wrapped in brackets for clarity.

var variable =(condition ?true:false);

To avoid misunderstandings for loops are always written in their long form, i.e. loop heads like for (var i = count; i--; ) should be avoided in favor of for (var i = count-1; i>=0; i--). Also there are spaces between the statements and you should write i++ instead of ++i.

for(var i =0; i <10; i++){}

try{}catch(err){}

Firebug prefers no braces, if they are not necessary.

if(...)
dump(true);else
dump(false);

But if one of the branches needs braces use them for all. Also note

if(...){
dump("0");
dump("1");}else{
dump(2);}

If the head of a control structure is wrapped into several lines because it is longer than the maximum line length, also use braces, even when the block just contains one line.

if(...
...){
dump("0");}else{
dump(2);}

Firebug prefers no brackets for operators like typeof.

if(typeof variable =="object")returnfalse;

Comments

Multi-line as well as single line comments should always be put into their own line.
So you should write:

// This is a commentvar abc = xyz;

Comments for blocks of code will be placed above them.

if(foo =="bar"){
...
}// foo is not set to "bar"else{
...
}

To describe what specific functions do, especially published APIs, JSDoc comments are used.

Firebug codebase also uses the following horizontal separator for dividing members of one object (this separator uses indentation (4 spaces) since it's used within an object scope that is indented (100 characters long).

Naming

American English is used for all labels and comments. That means, that you should write e.g. synchronize instead of synchronise or color instead of colour.

Functions and Methods

Functions should use camelCase but should not capitalize the first letter. Also functions names must start with a verb.

function initialize(){}

function getLocationList(){}

Objects

Constructors for objects should be capitalized and use CamelCase.

function ObjectConstructor(){}

Firebug.MyModule= extend(Firebug.Module,{});

MyObject.prototype=(){
myMethod:function(){}};

Constants

Constants should be capitalized as follows:

var MY_CONSTANT =true;

Use var instead of const, since the code can also be used in the browser environment where const is not supported.

Variables

Variables should use camelCase and not capitalize the first letter. Variable definitions should be done separately, not comma-separated. They don't have to be initialized immediately but before they are used.
If abbreviations are used, they should be written lower case at the beginning of a variable but in capitals when they are in the middle of the name. Also they should not be a single character.