baconbutty.com

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

MyFunctionCall(1,2,3);

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

if (a == b)
{

}

or

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.

E.g.

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

var MY_CONSTANT_VALUE = 1;

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()
{
	alert("someMethod");
};

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()
{
	alert("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.

E.g.

if (true)
{
	alert("true");
}


do
{
	alert(i);
}
while(i--);


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) {
    alert("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:-

• DOM-2-Core
• DOM-2-HTML
• DOM-2-Style
• DOM-2-EVENTS
• DOM-2-VIEWS
• DOM-2-TRAVERSAL

• DOM-3-Core
• DOM-3-Events
• DOM-3-Views
• DOM-3-LS
• DOM-3-AS
• DOM-3-Val
• DOM-3-XPATH

• Window
• SVG

E.g.

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