Escrevendo códigos mais limpos em .NET
A principal ideia deste artigo é encontrar pontos em nossos códigos que podem/devem ser melhorados em .net. Para escrever códigos legíveis, é necessário saber o que torna legível, para isso, técnicas simples, porém com um alto poder serão abordadas
Este Artigo faz parte da Revista easy .Net Magazine 33 Ver Revista
Artigo do tipo Exemplos Pontuais
Conteúdo sobre boas práticas, Artigo no estilo Mentoring.
A principal ideia deste artigo é encontrar pontos em nossos códigos que podem/devem ser melhorados. Para escrever códigos legíveis, é necessário saber o que torna legível, para isso, técnicas simples, porém com um alto poder serão abordadas de forma sucinta, clara e objetiva, visando ajudar a produzir um código limpo e autoexplicativo para que qualquer pessoa possa facilmente entendê-lo em um curto espaço de tempo.
É muito comum, quando vamos começar um novo projeto, pensarmos "Neste será diferente, irei comentar as rotinas.", ou ainda "Neste as coisas não fugirão do controle, como no último projeto.", etc. A ideia apresentada é muito válida, porém a realidade que vemos no decorrer do projeto é diferente, os pensamentos mudam ("Esta rotina será comentada depois", "Este trecho não é importante", "Está muito complicado, mas ninguém vai trabalhar com isso mesmo", etc.).
Na verdade, o intuito que tínhamos no início do projeto se perde facilmente com o tempo se não tivermos disciplina, foco e consciência do que estamos produzindo. Ou seja, temos que pensar além do código que estamos escrevendo hoje, tem que pensar sempre que o que codificarmos hoje necessitará de manutenção futuramente, serão necessários ajustes, correções, evoluções, etc. Sendo assim, é importante escrever o código de forma a minimizar o tempo que outra pessoa e até você mesmo precisará para entendê-lo posteriormente.
Temos que ter a consciência de que um código de fácil leitura, documentado e organizado fala por si só, ainda que pareça um pouco de utopia um código nestes padrões, já que a nossa realidade onde tudo que precisa ser desenvolvido deve ser feito do dia para a noite, não nos permite nem desenvolver algo com a qualidade que gostaríamos o que dirá bem documentado.
Porém, será que realmente a culpa é apenas do tempo que temos para desenvolver? Será que esse mesmo tempo que temos (ou não temos) justifica a falta de qualidade no código que escrevemos? Talvez não, a culpa é muitas vezes do desenvolvedor, pois o único responsável pelo seu código é você mesmo, então não coloque a culpa em outras pessoas ou outras coisas para justificar um código complicado, um código desleixado e sem preocupação.
Neste artigo serão apresentadas algumas sugestões para que os códigos produzidos a partir deste ponto sejam códigos com maior qualidade, tanto esteticamente quanto funcionalmente.
Nomes de variáveis e/ou rotinas
Variáveis ou rotinas devem conter em seus nomes informações relevantes que realmente ajudem a entender a função daquele elemento. Devemos evitar nomes como "tmp", ou "teste", ou ainda "xyz", ou seja, nomes demasiadamente genéricos. Para uma variável que armazena a soma de dois inteiros, por exemplo, ao invés de utilizar "variavel_de_retorno", devemos utilizar algo como "armazena_soma" ou "resultado_soma", etc., nomes mais concretos e que realmente explicitam o que a variável armazena.
Informações extras em nomes podem ser bem vindas, como o tipo de uma variável (int_idade para inteiro, ou sNome para string, por exemplo), que ao passar o olho você identifica o tipo da mesma. Também devemos tomar cuidado para que os nomes que damos a variáveis e/ou métodos não fiquem muito grandes, o que dificulta a sua utilização. Por exemplo, ninguém gosta de ler "metodoResposavelPorObterSaldoDevedorDoClienteNaLoja", o mesmo vale para nomes curtos e/ou abreviados demais como "obterSalDevCliLoja", que deixam uma grande margem para múltiplas interpretações. Além disso, palavras desnecessárias devem ser removidas. Ao invés de "ConvertToString", podemos utilizar "ToString", o que já deixa bem claro o que faz.