Blog Entry - 3rd June 2007 - Programming - JavaScript

JavaScript code style

These are the preferences I have for my JavaScript coding style:-

Spacing of Tokens

Tokens are all spaced-out, rather than compact:-

var a = 1 + 2 / (3 + 4);

preferred to

var a=1+2/(3+4);

I do not have spaces after opening and before closing brackets:-

var a = 1 + (2 + 3);

preferred to

var a = 1 + ( 2 + 3 );

Argument lists for functions are separated by a COMMA and a SPACE:-

MyFunctionCall(1, 2, 3);

preferred to


Flow-control statements can either have or omit a space between the keyword and the condition:-

if (a == b)



if(a == b)


Variable Names

Lower Camel Case for variables.

var name = "";
var longerName = "";

I no longer subscribe to the use of Hungarian Notation, where you prefix the variable with an indicator of its type or contents.


var aArray = [];
var bBoolean = false;
var nNumber = 0;
var sString = "";

If a variable to function as a constant then it is in all capitals with a _ to separate each word:-


Function Names

Upper Camel Case for functions which are stand-alone (i.e. not methods of an object).

function StandAloneFunction()


Constructor (Class / Object) Names and Methods

Where you use a Function as a constructor for an Object then I signal this with the prefix class.

function classMyObject()


var instance = new classMyObject();

This goes completely against the usual convention of simply using Upper Camel Case for class / object type names, so I don't expect to make any friends with this approach.

For functions which are methods of an object use Lower Camel Case

function classMyObject()


classMyObject.protoype.someMethod = function()

Function Declaration Blocks

I prefer the braces to each appear on their own line, even if there is only one statement in the function.

I also use the TAB character to indent statements in a function declaration.

function MyFunction()

Statement Blocks

Again, I prefer the braces to each appear on their own line, even if there is only one statement in the block.

Again, I also use the TAB character to indent statements in a block.


if (true)


var anonymousFunction = function()
	alert("Anonymous Function")l

This goes completely against the usual practice of having the first brace { appear on the same line as the start of the statement, and using four SPACES for indents, as follows:-

if (true) {

Type Annotations

I have subscribed to Nicholas C. Zakas's proposal for type annotations, which provides some anticipation of the type annotations in the future ECMAScript 4.

These appear in /*...*/ comment blocks.

The style looks as follows:-

var index /*: int*/ = 0;
var name /*: String*/ = 0;

function AddThese(
	value1 /*: Number*/,
	value2 /*: Number*/
) /*: Number*/
	return value1 + value2;

You will note that I put function arguments on separate lines, to aid readability.

The disadvantage is you cannot easily comment out large chunks of code. Thus -

var a /*: int*/ = 1;

- is a syntax error. So you will need to use // comments.

Otherwise I have not found these a particular problem, and indeed they have been a welcome discipline.

The only other practical problem with it is: what name do you use in the type annotation? At present I use the following scheme:-

1. Wildcard * (any type)

I use the Visual Basic Any type annotation :

/*: Any*/

2. ECMA3 Native Types

/*: Object*/

/*: Array*/

/*: String*/

/*: Number*/

/*: RegExp*/

/*: Boolean*/

3. ECM new native types

For floating point, I am sticking with Number:-

/*: Number*/

For integers:-

/*: int*/

/*: uint*/

For char, I am using String, as I don't think the current spec is proposing char as a separate data type.

/*: String*/

4. JavaScript DOM Bindings.

I am using the w3 interface names used in the ECMA Script DOM bindings such as those on the following pages:-


/*: HTMLElement*/

/*: HTMLIFrameElement*/

5. Other Host Objects (ActiveX, COM etc)

I am not sure how to deal with these.

At present, I am opting for

/*: HostObject(Scripting.FileSystemObject)*/

/*: HostObject(Word.Application)*/

or just

/*: HostObject*/

6. Union Types

For unions I am using

/*: (Boolean,Number)*/

7. For Array or Object property typing

The spec currently proposes the following, e.g. for an Array of elements of type String:-

/*: Array.<String>*/


Sorry, comments have been suspended. Too much offensive comment spam is causing the site to be blocked by firewalls (which ironically therefore defeats the point of posting spam in the first place!). I don't get that many comments anyway, so I am going to look at a better way of managing the comment spam before reinstating the comments.

Leave a comment ...

{{PREVIEW}} Comments stopped temporarily due to attack from comment spammers.