neteye.js

README.md

NETEYE JavaScript Code Style

This is JavaScript code style used at NETEYE. It's derived from the npm coding style which has been designed to reduce visual clutter and make bugs more apparent.

Indentation

Two-spaces. Tabs are better, but they look like hell in web browsers. And node uses 2 spaces, so that's that.

Configure your editor appropriately.

Line length

Keep lines shorter than 80 characters. It's better for lines to be too short than to be too long. Break up long lists, objects, and other statements onto multiple lines.

Quotes

Use single quotes unless your string itself contains single quotes which would otherwise need to be escaped. If you need to quote propery names in object literals use double quotes so that it looks more like JSON.

Whitespace

Put a single space in front of ( for anything other than a function call.

Bad:

function foo(bar) {
  if(bar) {
    baz (23)
  }
}

Good:

function foo (bar) {
  if (bar) {
    baz(23)
  }
}

For functions with empty paramter lists it's okay to omit the space:

setTimeout(function() { console.log('tick') }, 1000)

Also use a single space around curly braces and after each , or :.

Bad:

function foo(bar,64){ return {bar:bar,baz:baz} }

Good:

function foo (bar, 64) { return { bar: bar, baz: baz } }

Operators

Also use spaces around operators and after semicolons:

Bad:

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

Good:

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

Padding

Don't add padding around the contents of () and [].

Bad:

foo( 23, [ 1, 2, 3 ] )

Good:

foo(23, [1, 2, 3])

General

• Don't leave trailing whitespace at the end of lines.
• Don't indent empty lines.
• Don't use more spaces than are helpful.

Curly braces

Curly braces belong on the same line as the thing that necessitates them.

Bad:

function ()
{
  // ...
}

Good:

function () {
  // ...
}

If a block needs to wrap to the next line, use a curly brace. Don't use it if it doesn't.

Bad:

if (foo) { bar() }
while (foo)
  bar()

Good:

if (foo) bar()
while (foo) {
  bar()
}

Don't put else/catch/finally blocks in the same line as the closing brace of the if/try block.

Bad:

if (foo) {
  bar()
} else {
  boo()
}

Good:

if (foo) {
  bar()
}
else {
  boo()
}

Semicolons

Don't use them except in these situations:

• for (;;) loops. They're actually required.
• In front of a leading ( or [ at the start of the line. This prevents the expression from being interpreted as a function call or property access, respectively.
• case "foo": doSomething(); break

Much less common, but important to know:

• null loops like: while (something) ;
• Lines starting with + or -

Some examples of good semicolon usage:

;(x || y).doSomething()
;[a, b, c].forEach(doSomething)
for (var i = 0; i < 10; i ++) {
  switch (state) {
    case "begin": start(); continue
    case "end": finish(); break
    default: throw new Error("unknown state")
  }
  end()
}

Variable declarations

Don't manually hoist your var statements. It's okay to define them where they are used for the first time.

Bad:

function foo() {
  var i, j, k
  j = bar(23)
  for (i=0; i < 10; i++) {
    k = i + j
  }

Good:

function foo() {
  var j = bar(23)
  for (var i=0; i < 10; i++) {
    var k = j + i
  }
}

If you need use the same var in different blocks declare it before the first block.

Bad:

function foo() {
  if (bar) {
    var i = bar
  }
  else {
    i = baz()
  }

Good:

function foo() {
  var i
  if (bar) {
    i = bar
  }
  else {
    i = baz()
  }

Use separate var statements when assigning non-literal values. This makes stepping through the code inside a debugger much easier.

Bad:

var i = 23,
  j = foo(i),
  bar = baz()

Good:

var i = 23
var j = foo(i)
var bar = baz()

An exception to this rule are require() calls. In this case it's okay to use a comma-first notation:

var fs = require('fs')
  , path = require('path')
  , url = require('url')

For uninitialized variables or vars set to a literal value that fits into a single line it's okay to use the same pattern:

var foo
  , bar
  , baz = 23

For complex object or array literals use a separate var statement.

jshintrc

/* See http://www.jshint.com/docs/options */
{
  // Relaxing Options 

  "asi": true,      // allow missing semi-colons
  "laxcomma": true, // allow leading commas in multi-line var declarations
  "laxbreak": true, // allow improper line breaks
  "boss": true,     // allow assignments where conditions are expected
  "expr": true,     // allow expressions where assignments are expected  
  "loopfunc": true, // allow functions inside of loops
  "proto": true,    // allow using __proto__

  // Enforcing Options

  "immed": true,    // warn if immediately invoked functions are not wrapped in parenthesis
  "newcap": true,   // warn if uncapitalised constructor names are used
  "regexp": true,   // warn on unsafe usage of '.' in regular expressions
  "undef": true,    // warn when using undeclared variables
  "trailing": true, // warn when using trailing whitespace at the end of lines

  // Environments

  "node" : true,
  "browser" : true
}