MozillaZine

JavaScript coding guidelines

From MozillaZine Knowledge Base

(Difference between revisions)
Revision as of 11:29, 23 December 2005
Asqueella (Talk | contribs)
(reverting - previous example was correct, adding a note about non-triviality of this approach)
<-- Previous diff
Revision as of 11:29, 23 December 2005
Asqueella (Talk | contribs)
(Miscellaneous - remove dead link)
Next diff -->
Line 101: Line 101:
Even though javascript is an interpreted, garbage collected, language, it is still possible to leak memory, meaning that memory that is no longer being used will not be freed up for other applications. This is particularly true when accessing C++ components via XPCOM. Developers should read [http://www.mozilla.org/scriptable/avoiding-leaks.html Using XPCOM in JavaScript without leaking] to understand how to avoid causing memory leaks. Even though javascript is an interpreted, garbage collected, language, it is still possible to leak memory, meaning that memory that is no longer being used will not be freed up for other applications. This is particularly true when accessing C++ components via XPCOM. Developers should read [http://www.mozilla.org/scriptable/avoiding-leaks.html Using XPCOM in JavaScript without leaking] to understand how to avoid causing memory leaks.
-===Miscellaneous=== 
-*[[Dev : JavaScript variables | Variables in JavaScript]] 
[[Category:JavaScript]] [[Category:JavaScript]]

Revision as of 11:29, 23 December 2005

This page is part of the extension development documentation project.

Ask your questions in MozillaZine Forums. Also try browsing example code.

Note: development documentation is in process of being moved to Mozilla Development Center (MDC).

Contents

JavaScript coding guidelines

Here is a list of conventions (discuss). Some people disagree, but some think it's a good idea to follow them.

Naming Convensions

There are six basic rules.

  1. Every variable object name's 1st char should be a lower case.
    var myName = "Torisugari";
  2. Every constant object name should be upper cases.
    const MY_NAME = "Torisugari";
  3. Every constructor's name should begin with an upper case character:
    function MozillaZine(){
      this.description="A Cool Site";
      this.name="mozillaZine";
      this.url="http://www.mozillazine.org/";
    }
    var gMyFav = new MozillaZine();
    
  4. By prefix g the author means that is a global object, and unique in the window. Exception: A global function doesn't have to start with g.
  5. By prefix a the author means that is an argument.
  6. By prefix _ or m the author means that is a private member.

Bad examples, though gramatically correct (see next section for a good example):

var bar=0; /*bar should be gBar*/
function foo(){
  var gFoobar = 0; /* gFoobar is not a global value */
  return gFoobar;
}


function foo(bar){  /* bar should be aBar */
  var aFoobar="foo" + bar; /* aFoobar is not an argument */
  return aFoobar;
}


var gFoo={
  _bar:0
}

var foobar=gFoo._bar; /* _bar is a public member ? */
/* In other words, you can write only "this._bar" */

Avoiding name collisions

In order to avoid name collisions, use an unique prefix (for example, name of the extension) for identifiers in overlays (this also applies to XUL ids in overlays).

To avoid prefixing each identifier, you can put them inside an object with unique name:

var ExtensionName = {
  _privateMember: 3,
  publicMember: "A string",

  init: function() {
    this.doSomething(this.anotherMember);
  },

  doSomething: function(aParam) {
    alert(aParam);
  }
};

An even better way to modularize your code, that guarantees that private members are really private, is to wrap it in a constructor. This an advanced technique, and you need to understand JavaScript OO model well to successfully use it.

var ExtensionName = new function() {

  var something; /* private */
  function doThis() { ... } /* private */

  /* public constructor */
  this.SomeClass = function() {
    /* ... */
  };

  this.someotherthing = 35; /* public */
  this.doSomething = function() { ... }; /* public */
  
  function doSomethingElse() { ... }
  this.doSomethingElse = doSomethingElse;  /* public too */


};

Another script can then use:

ExtensionName.doSomething();
myObj = new ExtensionName.SomeClass();

Avoiding memory leaks

Even though javascript is an interpreted, garbage collected, language, it is still possible to leak memory, meaning that memory that is no longer being used will not be freed up for other applications. This is particularly true when accessing C++ components via XPCOM. Developers should read Using XPCOM in JavaScript without leaking to understand how to avoid causing memory leaks.