Destaques e observações que anotei enquanto assistia o webcast "Best of Fluent 2012: Maintainable JavaScript" da O'Reilly.

gistfile1.txt

Vídeo: https://www.youtube.com/watch?v=c-kav7Tf834
Slides: http://www.slideshare.net/nzakas/maintainable-javascript-2012

Linhas iniciadas com - são os tópicos que achei mais relevantes. Isso aqui não é uma transcrição do vídeo.
Linhas iniciadas com * são meus comentários.

- Código que você precisa manter
  - É todo código que não foi você que começou do zero
  - Código que você começou do zero, mas parou para tomar um café, quando voltar é código que você vai precisar manter como qualquer outro
  - A empresa se importa com código que deverá ser mantido. É uma questão de trabalho em equipe.
    * Uma pena que tenha empresas que não se importem, ainda que devessem.
  - Colegas de trabalho se importam (* ou pelo menos deveriam). Todo mundo já herdou código. Talvez você já tenha tenha ou vá herdar código que vc mesmo fez.
  * É ressaltada muitas vezes a diferença entre trabalhar com código que só você encosta e com código com qual uma equipe trabalha.
  - O trabalho que fazemos não é ensinado em escolas, todo mundo aprende por conta própria e acha que é a melhor forma do mundo
    * Parece óbvio, não custa repetir, e explica muito porque tudo é uma zona, e porque precisamos de processos otimizados.

- Code style
  - Existem vários padrões, não importa qual é o melhor, importa é que UM seja usado, e que seja o ÚNICO.
    * Usar um mesmo editor ou IDE, ou pelo menos um que se adeque ao padrão escolhido.
  - Programas são feitos para humanos LER e computadores EXECUTAREM. É por isso que não trabalhamos só com assembly.
  - Menos código em uma linha, menos probabilidade de conflito de versões.
  - Comentários. Poucos, mas quando necessários. E é bom considerar que é necessário em cada método / função.
  - Falta de comentários são uma fonte de bugs de regressão.
    * Nem todo mundo faz essa correlação.
  - Use nomes longos, lógicos, explicativos, para variáveis, e funções.
    * A menos que você trabalhe com algo como advpl, não se importe com tamanhos.
  - Nomes de funções como verbos. Especialmente retornos booleanos.
  - Javascript é inconsistente nos camelCases dos próprios métodos (XMLHttpRequest, por exemplo).
    * Sim, js é a linguagem do capeta, e muita gente age como se não fosse.

- Separar html, css e js.
  - Evitar a todo custo js inline.
    * Não havia dado tanta atenção a isso até agora...
  - Da mesma forma, não colocar html em strings js
    * Já isso, eu sempre evitei
  - Não usar js no css
    * WTF? Nem sabia que isso existia! Salvo pela ignorancia.
  - Manter css fora do js
    * Mas e para coisas dinâmicas? Apenas trocar classes entra na regra?

- Eventos devem ser tratados de forma simples. Delegue o que deve acontecer ao capturar o evento a outras funções.
- Use trow para erros personalizados em situações que você sabe que se ocorrer um erro, vai ser difícil debugar. Não exagere.
- Evite comparação com null
  * Entendo que por causa do tipo, mas não sei se eu usaria muito instanceof e typeof (que inclusive tem gotcha com null)
- Separar configuração de strings (urls, strings, html, configurações, valores repetidos no fonte)
  * Para strings talvez fique muito declarativo?

- Automação para minificação e concatenação de assets
    * Mesmo para coisas como advpl web, vale a pena usar ferramentas externas e adicionar um passo extra