JavaScript: Tools, Coding Standard and Guidelines

We’re currently devoting an hour each Monday to collectively work our way through JavaScript. Our aim is to point to the key areas of interest and improvement, and to dig into each area one by one.

We are maintaining a TOC for our JS-discussions here.

Development Tools

Firebug is the most important development tool for us, without comparison. Everyone is familiar with this time-tested tool.

You will rarely need more than Firebug, although there are some valid alternatives now, in 2010. Chrome, Safari and Opera (Dragonfly) have all internal tools for debugging (and more). None of us have used those tools extensively, so we don’t know more than what we have heard from third parties, which is mostly positive. If you need to spot errors in IE, Microsoft Script Debugger is your best hope. IE8 ships with this integrated as default. No-one in our team reported ever making use of the Firebug Light for IE.

When it comes to JavaScript editors, we find that no text editor seems to differ significantly from the rest. Most editors provide color-formatting, some provide API-reference with autocompletion and some editors like vim and TextMate can be configured for auto-validation through JSLint.

Coding Standard

Our coding standard for JavaScript builds on our own internal PHP Coding standard as far as it fits, which in turn builds on the publicly available Zend Framework Coding standard.

We have boiled our standard down to this shortlist.

  • Follow the Zend Framework Coding standard
  • Use an underscore in front of private objects. (i.e. var _private = 0;) Private objects and methods can be defined as «trusted» with everything else foreign and error-prone. This can make your core more stable and rigid without having to overdo it with data-testing and integrity validation.

It is possible to achieve a private scope in JavaScript, but it comes at a cost in complexity, and we have decided against it. Our decision is based on experience and advice given in “Pro Javascript Design Patterns“.

 * Rationale and short description of ClassName.
var objectName = {
    myFunction: function(whatToDo)
        if (typeof whatToDo === 'string' && whatTodo.length > 0) {
    _doWhatYouGottaDo: function(whatToDo) {
      // As this is a private function, I trust the type and data validity of the argument

The above is a minimal example, which in no way covers all the rules accurately.


Global scope. Put as little garbage as possible in the global scope. Use well-named objects as namespaces and if needed sub-namespaces. Know the results of using or skipping “var” when creating objects.

Use closures, with care! Closures are necessary in JavaScript, but as not all languages have them, they will to an inexperienced JS-programmer look too much like Magic(TM), which isn’t too good. Use good judgement when to use them, and  remember good inline commenting to make the magic more transparent.

Don’t use the “new” operator. When setting up prototype inheritance it has to be used, but there are no other cases where it should be used. In most cases it’s not only slow, but the alternatives are often easier to understand, require less code and are more powerfull. Because of this, we have decided to conform on code without new. As examples, new Array and new Object should be written as [] and {}.

Prototype inheritance contains power for object oriented code. We will return with more guidelines when our experience grow. We must admit not to have used this elaborately. A serious liability of PrototypeJS (the framework we used) is that it overrides prototype (the language feature) from JavaScript.

Few anonymous functions. As a rule of thumb, we say: name functions. This has to do with testability and readability of your code. The exception is if you need a “one-liner” to use just once, in which case anonymous functions are OK. You would normally not test these kind of functions.

Lint your code! Lint is a code quality tool, and it will hurt your feelings. But  that pain is just Douglas Crockford stabbing the parts of you responsible for writing bad JavaScript. You end up stronger in the end.

Recommended research material

JavaScript requires effort on your behalf. You need to do the homework if you want to be a powerful and successful JavaScript developer. For starters we recommend these resources: