Escrevendo códigos mais limpos em .NET

É 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.

Apesar da escolha de um nome adequado às vezes demor ...