Ferramentas de apoio na busca pela qualidade do código

As IDEs mais famosas possuem mecanismos integrados que ajudam a localizar possíveis erros de codificação, mas seu alcance ainda é limitado. Nesse campo entram os plugins e ferramentas citadas neste artigo: são ferramentas de análise de código estático que buscam por erros – e possíveis erros – de codificação ou de estilo, sem necessidade de execução ou teste do código desenvolvido.

A seguir uma breve introdução sobre algumas das ferramentas mais populares, que servem de apoio no dia a dia do desenvolvimento e revisão de código. Todas podem ser instaladas como plugin no Eclipse.

FindBugs

O FindBugs é uma das mais populares ferramentas de análise de código, sua análise é feita sobre o byte-code gerado. Sua implementação é baseada no conceito de bug patterns, onde um determinado conjunto de códigos muitas vezes indica um erro. Isso acontece por vários motivos, entre eles são destacados os seguintes:

  • Funcionalidades complexas da linguagem;
  • Entendimento não correto dos métodos disponíveis na API;
  • Erros do desenvolvedor: erros de digitação, uso incorreto de operadores booleanos.

Feita a análise, os problemas encontrados são agrupados da seguinte maneira:

  • Corretude: o código pode estar fazendo algo claramente não desejado, como referência a um objeto que pode causar Null Pointer Exception ou a chamada ao método equals() comparando classes não relacionadas;
  • Prática ruim: o código viola uma boa prática, como sobrescrever o método equals() sem sobrescrever o método hashCode() e declarar o serialVersionUUID como long, final ou static;
  • Concorrência: como uso incorreto de wait() e notify() ;
  • Performance: Uso de construtor de Integer, ao invés de Integer.valueOf(), chamada explícita ao garbage collector;
  • Código malicioso: como um campo estático declarado como um array mutável;

Possui uma lista extensa e bem detalhada dos problemas que podem ser encontrados disponível em http://findbugs.sourceforge.net/bugDescriptions.html.

Além disso possui um mecanismo para adição de checkers customizados.

PMD

O PMD é uma ferramenta de análise baseada no código fonte e também busca por potenciais problemas de código, além de indicar possíveis melhorias no código. Destacam-se:

  • Possíveis erros: trechos de tratamento de exceções vazios (try/catch/finally);
  • Código morto: variáveis e parâmetros não utilizados, métodos privados;
  • Código sub-otimizado: uso desnecessário de String/StringBuffer;
  • Expressões complicadas: uso desnecessário de ifs, fors que poderiam ser implementados como while;

Além disso, duas análises são destacadas: análise de complexidade ciclomática e a análise feita pelo CPD (Copy/Paste Detector), que detecta código duplicado, mostrando um potencial candidato a refactoring.

Possui uma série de regras que podem ser configuradas de acordo com a necessidade: http://pmd.sourceforge.net/pmd-5.0.4/rules/index.html

Checkstyle

O Checkstyle, como o próprio nome diz, é uma ferramenta de análise com foco no estilo de codificação e não na lógica ou integridade do código. Alguns pontos checados por ele:

  • Comprimento máximo da linha, em caracteres;
  • Identação por tabulações ou número de espaços;
  • Convenção de nomes de atributos e métodos;
  • Presença de javadoc em classes, atributos e métodos;
  • Presença obrigatória de cabeçalhos;
  • Limite no número de parâmetros e linhas dentro de um método;
  • Utilização dos pacotes e classes importadas dentro de outra classe.

Seu conjunto de regras padrão é extenso e seu uso requer uma boa configuração, visto que não é necessário ou desejável seguir todas as regras. As regras existentes estão disponíveis em http://checkstyle.sourceforge.net/availablechecks.html

UCDetector

Ferramenta de análise de código simples, disponível apenas para Eclipse, direta e com objetivo bem definido: encontrar código desnecessário:

  • Código desnecessário, ou seja, nunca executado;
  • Código que pode ter sua visibilidade diminuída, pelo uso restrito (método público deve ser declarado como privado, por exemplo);
  • Métodos e atributos que podem ser declarados como final;

Apesar da simplicidade, as alterações sugeridas devem ser aplicadas com cuidado. Essa ferramenta não consegue identificar código utilizado fora do contexto atual (na disponibilização de uma API, por exemplo), através de reflection ou em frameworks que não fazem uso direto das classes, como Hibernate e Spring.

Conclusão

Como visto, algumas ferramentas possuem funcionalidades comuns entre si, mas todos possuem suas particularidades e sua utilidade, dessa forma não é possível indicar apenas uma ferramenta, mas é recomendado que elas sejam utilizadas mesmo que para procurar um conjunto pequeno de problemas. Como nenhuma dessas ferramentas possui correção automática de código, a correção ainda é de responsabilidade do desenvolvedor, caso necessário.

Referências

Por MARCO ANTONIO ROCHA

Pai, marido, nerd e programador (não necessariamente nessa ordem). Analista de Sistemas ancorado na MATERA desde 2008. Desenvolvedor Java na maior parte do tempo, fuçador em tempo integral.

Postado em: 30 de julho de 2013

Confira outros artigos do nosso blog

REST não é JSON

21 de agosto de 2017

Bruno Sofiato

[Webinar] Profile de aplicações Java com Oracle Mission Control e Flight Recorder

24 de julho de 2017

Danival Calegari

Criando Mocks de serviços REST com SoapUI

27 de junho de 2017

Monise Costa

JavaScript 6: diferença entre var, let e const

09 de maio de 2017

Otávio Felipe do Prado

Deixe seu comentário