Concrete Logo
Hamburger button

Integrando ferramentas de análise de código em Android

  • Blog
  • 15 de Dezembro de 2015
Share

Parte 3: PMD

*Este post foi originalmente publicado no Medium e no Blog pessoal do autor.

Dando continuidade a nossa série de posts, hoje vamos conhecer o matador de bugs, o PMD. Apesar de parecer uma sigla, nem os criadores sabem o que PMD significa. Atualmente em sua versão 5.4.1, ele possui regras que denunciam desde try/catches vazios até código copiado.

Como o Gradle possui nativamente um plugin do PMD, sua integração é tão simples quanto as outras ferramentas que já vimos. Primeiramente, vamos aplicar o plugin no nosso arquivo build.gradle:

Da mesma forma que fizemos com as outras ferramentas, uma recomendação é adicionarmos a task que vamos criar à task check:

O próximo passo é criar a nossa task. Ela é muito semelhante àquela que criamos para o FindBugs, com a diferença de que as propriedades que utilizamos para configurar as regras de validação se chamam ruleSets e ruleSetFiles. Assim como o FindBugs, com o PMD também temos a possibilidade de gerar o relatório tanto em formato XML quanto HTML.

task completa fica assim:

O arquivo de configuração pmd-ruleset.xml contém as regras que serão aplicadas ao processo de validação dos nossos arquivos. Um exemplo:

Todas as regras disponíveis para o PMD podem ser encontradas aqui. E como o próprio pessoal do PMD diz, nenhuma regra é escrita na pedra, é possível remover determinadas verificações de um ruleset. No contexto do Android, um caso onde isso é necessário é quando adicionamos a regra de Import Statements e estamos utilizando o Espresso, cujo design visa a fluência na leitura dos testes escritos. Esse design muitas vezes acaba gerando um grande número de imports estáticos, o que entra em conflito com a regra TooManyStaticImports do PMD. Caso haja a necessidade de remover alguma regra de um ruleset, podemos fazer isso no arquivo de configuração desta forma:

Executando a task pmd em um terminal (ou utilizando o menu Gradle dentro do Android Studio), podemos ter uma análise de código baseada nas regras que configuramos.

Pegando como exemplo o ruleset android que adicionamos à nossa configuração, podemos simular o erro comum de utilizar a localização da memória externa hardcoded como /sdcard. Assim, temos como resultado o seguinte relatório:

1

O link no relatório leva até a descrição detalhada do problema no próprio site do PMD.

E é isso! Ficou alguma dúvida ou tem alguma contribuição? Deixe seu comentário abaixo.

Na próxima e última parte dessa série de posts, veremos como realizar um ajuste fino da execução do Lint para melhorar a qualidade do nosso aplicativo e evitar que problemas conhecidos e más práticas acabem afetando o desempenho em produção. Até lá!