7 erros de Java para vencer

Não há como negar a necessidade de um código limpo — código que seja consistente, intencional, adaptável e responsável. Pergunte a qualquer desenvolvedor e ele concordará que isso deve ser uma prioridade ao criar um projeto. Mas o código é tão bom quanto o seu elo mais fraco e, como pode ser visto nos dados de telemetria do SonarLint, ainda existem muitos problemas que aparecem na lista gigante de projetos analisados.

Embora alguns dos problemas possam parecer triviais, eles podem ter um impacto significativo no software quando se trata de segurança, desempenho e manutenção. Por isso compilei uma lista dos erros mais comuns que encontramos em projetos Java, dentre as mais de 600 regras que abrangem a linguagem, levando em consideração qualidade e segurança. Com isso em mente, você pode se preparar melhor para criar um código que seja continuamente consistente, intencional, adaptável e responsável – tudo com um enorme benefício e baixo nível de esforço.

1. Código comentado

O código comentado apenas representa um desafio à sua legibilidade, por isso deve ser removido para maior clareza. Isso elimina a incerteza para o leitor, pois pode ser difícil determinar se o código foi comentado temporariamente ou deveria ter sido apenas removido. Uma dica útil a seguir para isso: se não se aplicar ao recurso enviado, remova-o ou remova o comentário se for uma desativação temporária.

Aqui está um exemplo:

A boa notícia é que se você precisar do código comentado posteriormente, poderá simplesmente recuperá-lo do sistema de controle de versão.

2. Tags ‘TODO’ negligenciadas

Deixar esses comentários no código-fonte, que provavelmente terá uma longa vida útil, leva a um código incompleto que pode afetar o software em diversas frentes. Por exemplo, quando se trata de colaboração dentro de uma equipe, alguns membros podem não saber quais recursos serão incluídos na versão final. Essas tags também podem dar a impressão de que podem ser tratadas posteriormente, em vez de implementar essas partes agora e reduzir a chance de erros futuros. Além disso, os blocos TODO podem causar vazamentos no desempenho no futuro.

Aqui está um exemplo real de um projeto chamado Apache Camel com uma linha TODO lançada há quase uma década.

Para evitar esses problemas, não adicione novos blocos TODO. Em vez disso, implemente o recurso antes de enviar o código final — ou registre essas tarefas no gerenciador de tarefas para que fique claro como resolvê-las no futuro.

3. Literais de String Duplicados

Strings duplicadas levam a trabalho extra ou falta de alterações quando esses valores precisam ser alterados para se ajustarem às novas condições. Em vez disso, use constantes para armazenar literais de string. Isso facilita a refatoração e melhora a consistência da base de código.

Um exemplo de como fazer isso:

4. Alta Complexidade Cognitiva de Funções

Mais comumente, ouvimos falar de complexidade ciclomática, que mede quantos caminhos são usados ​​no código e ajuda a determinar a complexidade de leitura para uma determinada parte do código. Mas este conceito não pode ajudar a descobrir o nível real de manutenção que precisa de mais considerações do que apenas o número de condicionais ou loops.

Reduzir a complexidade do código é uma peça crítica para facilitar a refatoração, as correções e as evoluções, já que os desenvolvedores gastam muito mais tempo lendo o código do que escrevendo-o. Muitas vezes, os projetos podem ser difíceis de ler ou compreender, e esta questão torna difícil saber a sua intenção e lidar com a sua manutenção e evolução. Os desenvolvedores devem investir na refatoração de código com alto nível de complexidade cognitiva para que a base de código se torne mais fácil de entender e manter no longo prazo.

Com o novo código, é bom fazer referência ao índice de complexidade e investir tempo para reduzi-lo ao limite configurado que deve ser suficientemente baixo.

5. Elementos não utilizados

É fácil para os desenvolvedores, ao codificarem um novo recurso, criar elementos do código que eventualmente não têm um propósito. Esses elementos não causam erros de tempo de execução ou falhas nos testes, por isso podem ser difíceis de identificar, mesmo que precisem ser removidos. Mas, na pior das hipóteses, eles podem nos forçar a repensar totalmente o código.

Esses elementos não utilizados reduzem a legibilidade do código, o que torna ainda mais difícil identificar a intenção do código e pode causar falta de confiança na sua conclusão. Leve-os para fora. Verifique o código não utilizado e remova o que não for mais útil ou considere se está faltando código que possa usar esses elementos. Dê uma olhada:

6. Tipos brutos

Em Java, não use tipos genéricos sem parâmetros de tipo — isso evitará a verificação de tipo e a captura de código inseguro durante a compilação, o que torna tudo visível durante o tempo de execução. Em vez disso, use tipos específicos que permitam aos usuários dessas variáveis ​​entender o que realmente é esperado e eliminarão surpresas durante o tempo de execução. Veja abaixo:

7. Exceções genéricas lançadas

O uso de exceções genéricas evita que os métodos de chamada manipulem diferentes exceções geradas pelo sistema e erros gerados pelo aplicativo. Para evitar isso, crie um sistema customizado de exceções que forneça informações suficientes ao chamador para que ele decida o que fazer, totalmente equipado com uma lista detalhada e diferenciada de caches.

Evitar erros leva a um software melhor

Todos os desenvolvedores iniciam a codificação com a intenção de criar um produto final de alta qualidade, confiável, adaptável e seguro. Mas é fácil que esses erros cotidianos aparentemente pequenos atrapalhem esse objetivo. Tomar nota desses problemas no futuro e fazer o melhor para evitá-los apenas irá prepará-lo para o tipo de software de código limpo que permite que uma empresa prospere.

O post 7 erros de Java para conquistar apareceu pela primeira vez em The New Stack.