Clean Code
Autor: Frutei - Espaço Saúde | Publicado: 2012-03-01T07:57:00-08:00


Galera, recomendo darem uma lida nessa matéria pois é muito interessante.

Código Limpo&nbsp; 


     


     
      

Estive presente no Agile Brazil 2011, e dentre as várias palestras que assisti, uma que me fez pensar bastante foi a do Vinicius Teles, intitulada “O dia em que a Terra acabou parou, porque o software travou”
 . De forma bastante resumida, Vinicius disse que vários dos problemas 
que encaramos diariamente é culpa nossa, dos desenvolvedores, e ele tem 
razão. Vide os problemas&nbsp; (seja lentidão ou dificuldade de utilização) 
dos sistemas dos correios, aeroportos ou bancos, os quais geram filas 
quilométricas que todos temos que enfrentar. Ou seja, todos pagam pelos 
bugs dos sistemas que nós criamos!



Ele sugeriu um novo manifesto, o Manifesto Vergonha Na Cara, que estabelece que Código de verdade é código testado e limpo! Como
 também estou cansado de enfrentar código de péssima qualidade, resolvi 
fazer uma pequena contribuição; durante a palestra, foi sugerido como um
 dos primeiros passos a leitura do livro Clean Code do Uncle Bob,
 e como muita gente ainda não leu esse livro, criei um pequeno resumo, o
 qual, espero, desperte o interesse pelo mesmo, levando os leitores à 
produzir código limpo, já que, como foi muito falado durante o evento, programador profissional é aquele que produz código limpo e testado!



O resumo que fiz aqui é referente a apenas alguns tópicos do livro, 
os quais acho que devem ser os primeiros passos para um código melhor.








Nomes significativos



Nomes de classes, variáveis, métodos, etc, devem ser significativos, 
indicando claramente o que um método faz ou o que um atributo 
representa. A intenção deve ser visível através dos nomes. Crie nomes 
pronunciáveis para facilitar a comunicação, evite acrônimos e siglas.



Evite nomes confusos, os quais podem levar quem lê o código a conclusões erradas.



Use nomes que refletem o domínio do sistema, o contexto e os problemas que devem ser resolvidos.








Funções



Funções devem ser pequenas. Aliás, elas devem ser ainda menores. Deve haver apenas um nível de abstração por função.



Funções devem fazer uma coisa, e apenas uma. Novamente, utilize um 
nome que descreva bem o que a função faz. Utilize o menor número de 
argumentos possível, fazendo o máximo para que não passem de três.



Cuidado com “efeitos colaterais”, funções não podem fazer nada 
“escondido”. Use exceções ao invés de códigos de erro, e considere que 
tratar exceções é uma coisa.








Comentários



Comentários não salvam um código ruim. Procure explicar o que o código faz COM CÓDIGO.



Crie nomes de métodos e de variáveis informativos, ao invés de 
explicar com um comentário o que um método com um nome ruim faz. Use 
comentários para deixar uma expressão complexa mais clara, para avisar 
sobre as possíveis conseqüências de uma alteração, ou para ressaltar a 
importância de certo ponto do código.



Comentários ruins também poluem o código. Não escreva comentários 
redundantes, inúteis, ou pior, com falsas informações. Também não deve 
ser usado para indicar quando ou por quem foi alterado, para isso temos 
ferramentas de controle de versão. Não escreva comentários confusos ou 
grandes demais.



Não comente código que não será mais usado, simplesmente remova-o.








Objetos e estruturas de dados



Siga a Lei de Demeter. Faça boa abstração e encapsulamento. Não crie objetos burros.








Tratamento de erro



Use exceções ao invés de códigos de erro. Use exceções não checadas, e utilize mensagens de erro informativas.



Não retorne e nem passe null.








Testes



Siga as 3 leis do TDD.



Use uma assertiva por teste, e teste um conceito por vez.



Os testes devem ser rápidos, independentes, reprodutíveis em qualquer
 ambiente, auto-validáveis e escritos no momento certo. Mantenha o 
código de seus testes limpo.








Classes



Classes devem ser pequenas e seguir o princípio da responsabilidade única.
 Devem ser coesas, &nbsp;essa coesão resulta em classes pequenas. Classes 
devem ser criadas visando a mudança, então programe orientado à 
interface.



Outros pontos que não posso deixar de citar são: Todos os testes 
devem estar passando; refatoração deve ser feita constantemente, visando
 à melhoria contínua; código duplicado deve ser evitado a todo custo; 
classes e métodos devem ser pequenos; o código deve ser o mais 
expressivo possível.



Esse resumo é um levantamento de alguns pontos importantes, tanto que
 aqui é mostrado o que deve ser feito, não o porquê ou o como, isso pode
 ser encontrado no livro. Esse post é o primeiro passo, espero que todos
 dêem continuidade lendo esse livro e muitos outros, buscando criar um 
código melhor. Eu não quero mais código sujo atrapalhando a minha vida. E
 você?



As convenções de código são uma boa prática de programação. Ajudam por exemplo na
                    manutenção de um sistema. A violação dessas “regras” prejudicam em muito o entendimento
                    de uma API, por exemplo. Além do mais, com as convenções, se é capaz de produzir
                    um código legivel, “limpo”, que demonstra qualidade e de maneira profissional.





Fonte: http://vonjuliano.wordpress.com/2011/07/07/codigo-limpo/