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

+

==== Code Blocks ====

+

The Firebug codebase uses brackets on the next line like as follows:

<source lang="javascript">

<source lang="javascript">

Line 89:

Line 93:

// ...

// ...

}

}

+

+

foo("test", function bar()

+

{

+

// ...

+

});

</source>

</source>

-

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.

+

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 the definition of a config object or a one-line arrow function.

<source lang="javascript">

<source lang="javascript">

Line 100:

Line 109:

prop2: "value2",

prop2: "value2",

};

};

-

</source>

-

-

Anyway, class and function definitions should always have the braces on the next line as follows:

-

-

<source lang="javascript">

-

Firebug.MyModule = extend(Firebug.Module,

-

{

-

initializeUI: function()

-

{

-

},

-

});

-

</source>

-

-

<source lang="javascript">

-

function myFunction()

-

{

-

// ....

-

}

</source>

</source>

Line 125:

Line 116:

if (...)

if (...)

{

{

+

...

}

}

else if (...)

else if (...)

{

{

+

...

}

}

</source>

</source>

Line 154:

Line 147:

}

}

</source>

</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>

<source lang="javascript">

<source lang="javascript">

-

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

+

try

{

{

+

...

+

}

+

catch (err)

+

{

+

...

}

}

</source>

</source>

+

+

==== Loops ====

+

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>.<br/>

+

Also there are spaces between the statements and the operands and you should write <code>i++</code> instead of <code>++i</code>.

<source lang="javascript">

<source lang="javascript">

-

try

+

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

-

{

+

-

}

+

-

catch (err)

+

{

{

+

...

}

}

</source>

</source>

+

==== Ternary expressions ====

+

Ternary expressions must be wrapped in brackets for clarity.

+

+

<source lang="javascript">

+

var variable = (condition ? true : false);

+

</source>

+

+

==== Braces and brackets ====

Firebug prefers no braces, if they are not necessary.

Firebug prefers no braces, if they are not necessary.

Line 190:

Line 196:

else

else

{

{

-

dump(2);

+

dump("2");

}

}

</source>

</source>

Line 205:

Line 211:

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>

+

+

=== Operators ===

+

The use of the strict equal operator (<code>===</code>) is preferred over the normal equal operator (<code>==</code>).

+

+

=== Functions ===

+

Class and function definitions should always have the braces on the next line as follows:

+

+

<source lang="javascript">

+

Firebug.MyModule = extend(Firebug.Module,

+

{

+

initializeUI: function()

+

{

+

},

+

});

+

</source>

+

+

<source lang="javascript">

+

function myFunction()

+

{

+

// ....

+

}

+

</source>

+

+

There's one exception related to [https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions arrow functions]. If an arrow function is a simple one-liner, braces around the function body and the <code>return</code> statement are not necessary. If braces are set, they can be placed on the same line.

+

+

<source lang="javascript">

+

Object.defineProperty(dbg, "onExceptionUnwind", {

+

set: (hook) => { threadHook = hook; },

+

get: () => threadHook

+

});

</source>

</source>

Line 210:

Line 254:

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

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

Required modules at the top of a module should be listed in a specific order. That is:

+

+

# <code>firebug/firebug</code>

+

# <code>lib/trace</code>

+

# Other <code>lib/</code> modules

+

# Other modules

+

+

<source lang="javascript">

+

define([

+

"firebug/firebug",

+

"firebug/lib/trace",

+

"firebug/lib/css",

+

"firebug/lib/dom",

+

...

+

"firebug/chrome/eventSource",

+

"firebug/chrome/infoTip",

+

...

+

],

+

</source>

+

+

The preferred sorting order for the other modules is alphabetically ascending.

== Naming ==

== Naming ==

Line 235:

Line 334:

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

+

+

Functions names must start with a verb. There are two exceptions to this rule, though:

+

+

* Functions passed as parameters to another function, i.e. callbacks. They can be named just <code>callback</code> or describe the event when they are called.

+

* Event handlers should be prefixed by "on" to describe when the handler is called.

<source lang="javascript">

<source lang="javascript">

-

function foo()

+

function initialize()

+

{

+

...

+

}

+

</source>

+

+

<source lang="javascript">

+

function getLocationList()

+

{

+

...

+

}

+

</source>

+

+

<source lang="javascript">

+

function eachPanel(callback)

+

{

+

...

+

}

+

</source>

+

+

<source lang="javascript">

+

function setBreakpoints(afterBreakpointsAdded)

{

{

+

...

}

}

</source>

</source>

<source lang="javascript">

<source lang="javascript">

-

function myFoo()

+

onBreakpointAdded: function(context, bp)

{

{

+

...

}

}

</source>

</source>

Line 254:

Line 381:

function ObjectConstructor()

function ObjectConstructor()

{

{

+

...

}

}

</source>

</source>

Line 268:

Line 396:

myMethod: function()

myMethod: function()

{

{

+

...

}

}

};

};

Line 282:

Line 411:

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

=== Prefixes ===

=== Prefixes ===

Firebug codebase doesn't use any prefixes for member fields.

Firebug codebase doesn't use any prefixes for member fields.

+

+

=== Preferences ===

+

Firebug preference names are written in camelCase and are made up by `extensions.firebug.` + preference name. If the preference is related to a specific module, prepend it by its name.

+

+

<source lang="properties">

+

extensions.firebug.showFirstRunPage

+

extensions.firebug.netShowBFCacheResponses

+

</source>

== Good Practices ==

== Good Practices ==

Line 301:

Line 442:

initialize: function()

initialize: function()

{

{

+

...

},

},

shutdown: function()

shutdown: function()

{

{

+

...

}

}

});

});

Line 336:

Line 479:

</source>

</source>

-

== Example File ==

+

=== Strict Mode ===

-

Example of a typical Firebug file implementing a module object. Firebug namespaces (FBL.ns) are no longer the preferred way for Firebug files. See AMD below.

+

+

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

Latest revision as of 08:32, 30 April 2014

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!

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

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 the operands and you should write i++ instead of ++i.

There's one exception related to arrow functions. If an arrow function is a simple one-liner, braces around the function body and the return statement are not necessary. If braces are set, they can be placed on the same line.

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

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.