Galera, recomendo darem uma lida nessa materia pois e muito interessante.Codigo Limpo Estive presente no Agile Brazil 2011, e dentre as varias 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 varios dos problemas que encaramos diariamente e culpa nossa, dos desenvolvedores, e ele tem razao. Vide os problemas (seja lentidao ou dificuldade de utilizacao) dos sistemas dos correios, aeroportos ou bancos, os quais geram filas quilometricas que todos temos que enfrentar. Ou seja, todos pagam pelos bugs dos sistemas que nos criamos!Ele sugeriu um novo manifesto, o Manifesto Vergonha Na Cara, que estabelece que Codigo de verdade e codigo testado e limpo! Como tambem estou cansado de enfrentar codigo de pessima qualidade, resolvi fazer uma pequena contribuicao; durante a palestra, foi sugerido como um dos primeiros passos a leitura do livro Clean Code do Uncle Bob, e como muita gente ainda nao leu esse livro, criei um pequeno resumo, o qual, espero, desperte o interesse pelo mesmo, levando os leitores a produzir codigo limpo, ja que, como foi muito falado durante o evento, programador profissional e aquele que produz codigo limpo e testado!O resumo que fiz aqui e referente a apenas alguns topicos do livro, os quais acho que devem ser os primeiros passos para um codigo melhor.Nomes significativosNomes de classes, variaveis, metodos, etc, devem ser significativos, indicando claramente o que um metodo faz ou o que um atributo representa. A intencao deve ser visivel atraves dos nomes. Crie nomes pronunciaveis para facilitar a comunicacao, evite acronimos e siglas.Evite nomes confusos, os quais podem levar quem le o codigo a conclusoes erradas.Use nomes que refletem o dominio do sistema, o contexto e os problemas que devem ser resolvidos.FuncoesFuncoes devem ser pequenas. Alias, elas devem ser ainda menores. Deve haver apenas um nivel de abstracao por funcao.Funcoes devem fazer uma coisa, e apenas uma. Novamente, utilize um nome que descreva bem o que a funcao faz. Utilize o menor numero de argumentos possivel, fazendo o maximo para que nao passem de tres.Cuidado com efeitos colaterais, funcoes nao podem fazer nada escondido. Use excecoes ao inves de codigos de erro, e considere que tratar excecoes e uma coisa.ComentariosComentarios nao salvam um codigo ruim. Procure explicar o que o codigo faz COM CODIGO.Crie nomes de metodos e de variaveis informativos, ao inves de explicar com um comentario o que um metodo com um nome ruim faz. Use comentarios para deixar uma expressao complexa mais clara, para avisar sobre as possiveis consequencias de uma alteracao, ou para ressaltar a importancia de certo ponto do codigo.Comentarios ruins tambem poluem o codigo. Nao escreva comentarios redundantes, inuteis, ou pior, com falsas informacoes. Tambem nao deve ser usado para indicar quando ou por quem foi alterado, para isso temos ferramentas de controle de versao. Nao escreva comentarios confusos ou grandes demais.Nao comente codigo que nao sera mais usado, simplesmente remova-o.Objetos e estruturas de dadosSiga a Lei de Demeter. Faca boa abstracao e