1. Formato básico

Indentación

Se recomiendan 4 espacios por nivel; puedes configurar el editor con tab = 4 espacios y conversión automática.

Punto y coma

No omitas los puntos y coma para evitar errores de ASI (inserción automática de punto y coma).

Ancho de línea

Cada línea de código no debe superar los 80 caracteres; si es demasiado larga, se debe dividir manualmente con operadores.

Salto de línea

El operador va al final de la línea anterior y la siguiente línea se sangra 2 niveles. Si es una sentencia de asignación, también debe alinearse con la parte posterior al signo igual.

Línea en blanco

Debe haber líneas en blanco entre declaraciones de funciones, entre declaraciones de variables y declaraciones de funciones, y entre bloques lógicos dentro de una función.

El autor Nicholas también recomienda dejar una línea en blanco en la parte superior de los bloques de control de flujo, pero el ejemplo que da no es muy claro.

Nomenclatura

• Nombres de variables/funciones: regla Camel (camelCase), la primera palabra comienza con minúscula, las palabras siguientes comienzan con mayúscula y el resto en minúsculas.
• Nombres de constantes: estilo C, todo en mayúsculas, separando palabras con guion bajo.
• Constructores: regla Pascal, todas las palabras comienzan con mayúscula y el resto en minúsculas.

Literales

• Cadenas: entre comillas dobles, para saltos de línea usa el operador [+], no uses el carácter de escape \.
• Números: no omitas la parte antes o después del punto decimal, no uses forma octal.
• Null: usa null solo como marcador de posición para Object; no lo uses para detectar parámetros formales ni variables no inicializadas.
• Undefined: deberías inicializar todos los objetos con null para distinguir entre indefinido y no inicializado.
• Literales de objeto/array: no declares objetos y arrays con el constructor.

2. Comentarios

P.D. En el libro hay una explicación muy clásica:

Appropriately written comments help tell the story of code, allowing other developers to drop into a part of the story without needing to hear the beginning.

Comentarios de una línea

• Fin de línea: sepáralo del código con 1 nivel de sangría, y después de // debe haber un espacio.
• En una línea propia: se usa para comentar lo siguiente, debe mantener la misma sangría que el código comentado.
• Inicio de línea: se usa para comentar varias líneas de código.

Comentarios de varias líneas

Se usan para envolver grandes bloques de comentarios; se recomienda el estilo Eclipse, por ejemplo:

/*
 * comment line1
 * comment line2
 */

Nota:

• Deja una línea en blanco encima del comentario de varias líneas.
• Deja un espacio después del asterisco *.
• El comentario de varias líneas debe tener al menos tres líneas (porque no se añaden comentarios después de la primera y la última línea).

Dónde añadir comentarios

• Código que no se explica por sí mismo
• Partes intencionales que parecen tener errores.
• Hacks específicos del navegador

Comentarios de documentación

Deberías añadir comentarios a cada función, incluyendo descripción de funcionalidad, parámetros, valor de retorno, errores lanzados, etc. Por ejemplo, el estilo Eclipse recomendado:

/**
 * 添加指定元素到默认数组
 *
 * @method add
 * @param {Number} 将要添加的元素
 * @return {Boolean} 添加成功/失败
 * @throw {TypeError} 参数类型不匹配
 */
function add(item){
    if(typeof item === "number"){
        arr.push(item)
    }
    else{
        throw new TypeError();
    }
}

3. Sentencias y expresiones

Alineación de las llaves

Se recomienda el estilo de llave al final de la línea; no se recomienda el estilo de llave en la siguiente línea.

Espacios en sentencias de bloque

Después de if, los paréntesis llevan un espacio antes y después. Por ejemplo:

if (expr) {
    code
}

Sentencia switch

• Sangría: case se alinea con switch, break se sangra 1 nivel.
• Fallthrough de case: usa una línea en blanco o el comentario //falls through para indicar que el fallthrough de case es intencional.
• default: mantén default o usa el comentario //no default para indicar que no hay default.

P.D. Douglas, autor de "JavaScript: The Good Parts" (JavaScriptque en el lenguaje精粹), considera que no se debe usar el fallthrough de case (lo llama "costilla de pollo", es decir, algo inútil), porque es muy fácil provocar errores, mientras que Nicholas opina que basta con una línea en blanco o un comentario para aclararlo.

Sentencia with

No se usa.

Bucle for

Todas las variables deben declararse al inicio del cuerpo de la función, incluidas las usadas en la parte de inicialización del bucle for, para evitar errores causados por el hoisting (elevación) (puede ocultar variables globales).

Bucle for-in

No lo uses para recorrer arrays; cuando lo uses, recuerda añadir el filtro hasOwnProperty. Si intencionalmente recorres propiedades del prototipo, debes explicarlo con un comentario.

4. Variables, funciones y operadores

Declaración de variables

Cuerpo de la función = declaraciones de variables + declaraciones de funciones + sentencias lógicas. Separa cada parte con líneas en blanco.

Declaración de funciones

Primero declara y luego usa. Nunca pongas declaraciones de funciones dentro de ramas if, porque los navegadores lo interpretan de manera distinta y ES no establece un estándar.

Llamada a funciones

No añadas espacios antes o después de los paréntesis para evitar confundir con sentencias de bloque.

Ejecución inmediata de funciones anónimas

Envuelve la función anónima de ejecución inmediata entre paréntesis para evitar confundirla con una declaración de función anónima.

Modo estricto

No actives el modo estricto en el ámbito global; actívalo solo dentro de funciones. Para varias funciones, puedes usar una función anónima de ejecución inmediata para limitar el ámbito del modo estricto.

Comparación de igualdad

Usa solo === y !==.

eval

No uses eval() ni new Function(); usa funciones anónimas para optimizar setTimeout() y setInterval().

Tipos de envoltura básicos

No uses new Boolean(), new String(), new Number().

Referencias

• 《Maintainable JavaScript》
• JavaScript: The Good Parts

Fuente: http://www.codeceo.com/article/javascript-code-style-guide.html