Codificação limpa

Muitas vezes são vistos códigos extremamente complexos e extensos, e por este motivo acima de tudo, este código deve ser o mais limpo possível e o ajudará a economizar recursos, tempo, dinheiro, manutenção. Por este motivo abaixo estão algumas dicas para uma codificação limpa.

1 - Resultados de condições booleanas

Um erro muito comum nas codificações envolve as condições booleanas para atribuir resultados, veja o exemplo abaixo:

Este código pode ser substituído por apenas uma linha, facilitando até mesmo a interpretação da regra:

2 - Negando a negação

Seja cauteloso no código para evitar condições que neguem negações:

Ao ler este código, pensamos: “Espere aí… se a função avalia se o cliente não está ativo, mas tem um not… então a condição verifica se ele está ativo?!”. Sim! E se este é o caso, vale muito a pena reescrevê-la:

3 - Concatenação de strings

É comum encontramos códigos como esse:

Observe que há 4 operadores de adição (+) utilizados para concatenar o texto, dificultando a visualização do texto como um todo. Na verdade, essa dificuldade é exponencial. Quanto mais operadores existirem, mais difícil será a visualização.

Para evitar o uso demasiado deste operador, basta recorrer à função Format que é nativa do compilador e que permite declarar um texto com parâmetros e preenchê-los em um array:

4 - Incrementar/Decrementar valores

Podemos incrementar ou decrementar uma variável dessa forma:

Contudo, considere a utilização das funções Inc e Dec, presentes no Delphi desde suas primeiras versões:

5 - Condições if aninhadas

Algumas vezes tende-se a trabalhar sempre com resultados verdadeiros em condições if.

Essas condições aninhadas exigem a construção de uma “sequência lógica” em nossa memória para que possamos acompanhar o fluxo de execução. Entretanto, em certo ponto, naturalmente nos perdemos em meio à tantas condições, que se agravam ainda mais quando há fluxos alternativos (else).

Para “limpar” este código, pode-se empregar condições de guarda com instruções de saída do método:

6 - Chamadas repetidas com longos namespaces

Já encontrei códigos parecidos com este:

Para a leitura, é muito mais cômodo atribuir parte dos namespaces à uma variável e utilizá-la nas instruções seguintes:

7 - Tipos de dados inadequados

Cada tipo de dado usa uma porção de espaço na memória. Por exemplo, o tipo integer ocupa 4 bytes devido à sua dimensão, que pode atingir um valor de até pouco mais de 2 bilhões. Pensando assim, será que faz sentido criar uma variável que se refere a um dia do mês como integer?

Sabe-se que o valor máximo para o dia do mês é 31, então se o tipo integer passa de 2 bilhões, o espaço total alocado na memória jamais será utilizado. Então a recomendação é que seja substituído o integer pelo byte.