O documento apresenta princípios de código limpo, como usar nomes significativos para classes, funções e atributos; comentar apenas quando necessário para explicar a motivação do código; formatar o código de acordo com convenções; escrever funções e classes com uma única responsabilidade; aplicar o princípio DRY (Don't Repeat Yourself); evitar acoplamento e depender de entidades estáveis; usar herança para abstrair comportamentos.

1. Código Limpo
Wesley Fuchter

2. Use nomes significativos.
- Use convenções: Classe = Substantivo; Função = Verbo (infinitivo).
- Nome de função devem falar o que a mesma faz.
- Não há limites de caracteres para os nomes.
- Nomes de atributos devem representar a característica para que ele foi
criado.

3. Comente o necessário. Tenha poucas
necessidades.
- Evite comentário para explicar código. Para isso, escreva o código de
forma legível.
- Comente a motivação do código.
- Mantenha o comentário atualizado.
- Se for comentar, escreva bem.
- Não comente código. Exclua-o.

4. Formate o código. Tome cuidado com a
aerodinâmica.
- Formate o código conforme convenções.
- Tome cuidado com o nível de entrada do seu código.
Alta aerodinâmica pode ser resultado de muitas
responsabilidades.

5. Uma função, uma responsabilidade.
- Funções devem fazer bem apenas uma coisa.
- Funções devem receber poucos parâmetros.
- Parâmetros são para entrada - não para a saída.
- Evite parâmetros lógicos. Normalmente são usados para dar duas responsabilidades para a
função.
- Busque reúso.
- Não retorne null.
- Escreva testes de unidade. Escreva unidades testáveis.

6. Classes: responsabilidades pequenas.
- Classes devem ser coesas.
- Devem representar uma real entidade do domínio;
- Encapsule suas características. Exponha seus comportamentos.
- Mantenha o acesso mais restrito possível.
- Estabeleça pré e pós condições aos comportamentos. Encapsule-as.
- Conheça os estados do objeto. Controle suas mudanças.
- Delegue complexidade de criação.

7. Princípio: Don't repeat yourself.
- Códigos duplicados = metade da manutenibilidade.
- Busque coesão da função/classe.
- Evite múltiplas responsabilidades.
- Duplicou, realize a extração.

8. Pense em coesão. Evite o acoplamento.
- Demeter Law - Não converse com estranhos.
- Use composição.
- Receba as dependências, não as crie.
- Dependa de entidades mais estáveis que você.
- Inversão de Controle e injeção de dependências.

9. Use herança. Abstraia comportamentos.
- Prefira polimorfismo. Evite condicionais.
- Entenda a regra: “é um” / “é uma”.
- Feche para alteração, abra para extensão.
- Aperte as pré condições. Afrouxe as pós condições.

10. Próximos passos:
- Orientação a Objetos - de verdade.
- Princípios SOLID.
- Design Patterns - (GoF, J2EE, etc…).
- Livros:
- Refactoring - Martin Fowler;
- Domain Driven Design - Eric Evans;
- Working Effectively With Legacy Code - Michael Feathers;
- Test Driven Development - Kent Beck;

11. Obrigado.