"O pior dos problemas da gente é que ninguém tem nada com isso." Mario Quintana

Sou da opinião de que uma das primeiras coisas que um programador deve fazer é conhecer as boas práticas para escrita de código limpo. Nesse contexto, um dos livros que acho essencial para programadores de qualquer linguagem é o Clean Code do Robert C. Martin.

Aqui, entretanto, o foco é particular em JavaScript, então tomei como referência a primeira seção do livro Maintainable Javascript do Nicholas Zackas e fiz um resumo das melhores partes:

1. Fim de Declaração

Um dos mais confusos recursos do Javascript é sua capacidade de inserção automática de ponto-e-vírgula(ASI - Automatic Semicolon Insertion) no final de declarações. As regras de ASI são tão difíceis de lembrar que é melhor não optar pelo uso. Simplesmente coloque o ponto-e-vírgula ao final de declarações, conforme recomendam Douglas Crockford e o Google Javascript Style Guide.

Um exemplo do que pode acontecer é que o código abaixo:

//código ruim
function problem(){  
    return 
    {
          name: "problema"
    }
}

Acaba sendo transformado para:

//código ruim
function problem(){  
    return; 
    {
          descricao: "problema"
     };
}

A melhor maneira seria:

//código bom
function noProblem(){  
    return {
          descricao: "sem problemas"
     };
}

2. Quebra de Linha

O máximo de caracteres recomendado por linha na maioria dos guias de estilo de código é 80. Se alguma linha de código sua passar desse limite em uma declaração de função ou de string, é recomendável quebrá-la depois do operador e utilizar dois níveis de indentação:

// bom: quebra de linha depois do operador e dois níveis de indentação
longFunction(argument1, argument2, argument3, argument4, argument5, argument6,  
          argument7);
// ruim: Um nível de indentação
longFunction(argument1, argument2, argument3, argument4, argument5, argument6,  
      argument7);
// ruim: Quebra antes do operador
longFunction(document, element, window, "some string value", true, 123  
         , navigator);

Uma situação em que tive a desagradável experiência de constatar comportamentos inesperados foi quando invoquei uma função recebendo um argumento string muito longo. Neste caso, novamente é recomendado a quebra de linha depois do operador:

// ruim: não há utilização do operador
longStringFunction("inicio1;inicio2;incicio3;inicio4;fim1;fim2;

fim3;fim4;meio1;meio2;meio3;meio4;continua1;continua2;continua3");

// bom: utiliza o operador (+)
longStringFunction("inicio1;inicio2;incicio3;fim1;" + 

"fim3;fim4;meio1;meio2;meio3;"); 

O mesmo é válido em condicionais muito extensos, então quebre a linha depois dos operadores '&&' ou '||' e utilize dois níveis de indentação.

Obs: Declarar funções com muitos argumentos é uma má prática de programação, mas esteja preparado para esse tipo de situação, pois nem todo código que você utilizará será feito por você.

3.Usando comentários

A utilização de comentários é considerada má prática entre a maioria dos programadores. Isso porque a maneira correta de escrever código é dar significado a ele de modo que seja tão facilmente entendido como um texto qualquer em português, inglês ou qualquer outra linguagem humana.

Isso, porém, não é tão fácil de fazer quanto parece principalmente porque a maioria dos desenvolvedores não é tão experiente a esse ponto e porque a tarefa é difícil mesmo. Por causa disso, muitas vezes você acaba sendo incumbido de resolver um problema, mas se depara com um arquivo gigantesco sem nenhum comentário e código difícil de entender. Isso a princípio não deveria ser nenhum empecilho, desde que o tempo para resolver o problema fosse razoável, mas a maioria das vezes não é assim: o tempo é limitado, bastante limitado. Nessas horas você gostaria de ter, pelo menos, um panorama geral do que está acontecendo para poder agir mais rápido e precisamente.

Existem situações, entretanto, em que a utilização de comentários é sempre recomendada. Normalmente, é quando seu código possui uma intenção não aparente, vejamos:

// ruim: intenção aparente

// tamanho do array
var tamanho = array.length;  

// bom: intenção não é aparente

// valor 10 está sendo utilizado por razões de performance
//mudá-lo faria o mar virar sertão!
var tamanho = 10;  

4.O With Statement

A utilização do with no código, além de ser suscetível a erros, descontextualiza o código, deixando-o mais difícil de entender. Nem o próprio comitê do ECMA recomenda mais sua utilização.
Atualmente, com tantos bons editores de texto não há sequer razão para querer "economizar dedo".

Exemplo do MDN:

var a, x, y;  
var r = 10;

with (Math) {  
  a = PI * r * r;
  x = r * cos(PI);
  y = r * sin(PI / 2);
}

5.Uso de continue em loops.

Ao contrário do break que interrompe toda a iteração do loop, o continue 'salta' apenas valores específicos. Seu uso é pouco recomendado, porque na maioria das vezes pode ser evitado. No entanto, não é proibido usá-lo, apenas o use com cautela, sabendo que a legibilidade do código é o que pesa mais na decisão.

Exemplo do MDN:

var i = 0;  
var n = 0;

while (i < 5) {  
  i++;

  if (i === 3) {
    continue;
  }

  n += i;
}

É mais legível, porém, optar por:

var i = 0;  
var n = 0;

while (i < 5) {  
  i++;

  if (i !== 3) {
    n += i;
  }

}

6. Strict Mode

O modo strict está disponível desde o ECMAScript5 e seu uso é muito recomendado por 'forçar' o código a se enquadrar em bons padrões. Declarar, entretanto, "use strict" no escopo global pode ter consequências indesejáveis principalmente quando você está comprimindo vários scripts em um só e muitos deles são scripts antigos que não se enquadram no "modo estrito", ficando, portanto, suscetíveis a erros.

// Ruim - strict mode no escopo global
"use strict";
function strictFunction1() {  
    // code
}

function strictFunction2() {  
    // code
}

// Melhor maneira
(function() {
    "use strict";
    function doSomething() {
        // code
    }
    function doSomethingElse() {
        // code
    }
})();

7. Equality == Vs ===

Ok, não é necessariamente um problema de estilo, mas vamos lá:

Evite o uso de == ou !=. Ao invés disso, procure sempre utilizar === ou !==. O uso dos dois primeiros acarreta no chamado 'type coercion'.Isso significa que na comparação de variáveis de tipos diferentes o JavaScript acabará transformando um tipo no outro para só então proceder com a verificação de igualdade de valores. As consequências são comportamentos um tanto inusitados e você, com certeza, vai querer evitá-los:

console.log(5 == "5");  // true  
console.log(25 == "0x19");  // true  
console.log(1 == true);  // true  
console.log(0 == false);  // true  
console.log(2 == true);  // false  

Veja Também

• 6 Boas Práticas Que Todo Profissional JavaScript Deveria Conhecer