Código limpo
Autor: Ellison | Publicado: 2012-04-25T08:58:00-03:00

Todos sabemos a importância que é escrever um código que seja legível paraque posteriormente caso necessário seja possível adicionar mais features para o sistemasem muito esforço. Código, porém pode ser escritos de várias formas, aqui neste textodeixarei alguns conhecimentos que obtive lendo o livro Clean Code do autor Robert C.Martin. Não terminei de ler o livro ainda, e há algumas "técnicas" das quais também nãoconcordei sobre ser um código bom o que escreverei aqui não será tudo que aplico aoprogramar, mas o que está no livro.O primeiro assunto que achei interessante no livro é quanto as funções, segundoMartin funções boas são funções pequenas, (numa média de 20 linhas) caso sua funçãocresça demais você pode pegar parte dela e criar uma outra função com um nomeapropriado, além de deixar a função menor você pode com o nome da função fazer umresumo do bloco de código ao qual está funcionalizando agilizando sua leitura posterior.Outra questão referente a funções é que esta deve realizarsomente uma tarefa, caso em seu código haja, por exemplo, a funçãoverificarDadosSalvarNoBancoEfeutaLog(), que é uma função que faz “N” tarefas,ficaria melhor se separa-se cada função e cada uma fizesse uma única tarefa.O autor diz também que função boa, é função com o menor número deparâmetros possível, pois desta forma pensamos menos na sua chamada. Um exemploé a classe StringBuffer de java, onde lá dentro da classe há uma variável que recebea string, e em seguida nas chamadas para manipulação não precisamos em momentoalgum passar a String para suas funções, pois ela já está incorporada no objeto. Poremisso fica bacana quando os parâmetros não costumam se alterar muito, por exemplo,numa operação soma criar uma classe com parametros:SumObject.Numero1 := 2;SumObject.Numero2 := 2;SumObject.Somar();Caso se precise somar dois números, como a passagem de parâmetros é simples, umafunção de dois parâmetros fica boa.O livro também fala de nomeação de funções, variaveis, classes etc. O nome nãoprecisa ser bonito, mas tem que ser informativo sobre a função que a entidade nomeadao fará, mesmo que o nome fique um pouco comprido, mas que revele a intenção donomeado então está valendo. Um caso em que é necessário dar um nome melhor équando o individuo nomeia uma variável e logo em seguida ele coloca um comentáriodizendo pra que a variável serve. Neste caso é melhor evitar o comentário e colocar umnome que não necessite de comentário, assim caso alguém já pegue o código e veja autilização da variável já pode saber o que ela faz.Outro ponto interessante que achei no livro foi quanto a comentários de código,tais comentários podem encher o código fonte de código não mais utilizados e queninguém vai querer apagar, afinal de contas pode ser "importante" e pode ter umsignificado dentro do contexto ao qual está inserido, desta forma quando se comentarum código e no fim das alterações é recomendado que se dê o fim no código que nãoserá mais utilizado pois alguém pode se confundir com ele ali, atualmente os sistemasde controle de revisões já permitem maior segurança em apagar códigos antigos ounão deixar um histórico dentro do código fonte.