Integrando Ferramentas de Análise de Código no Android — Parte I: Checkstyle

Padrão

Sempre que começamos a escrever código, por mais simples ou complexo que seja, sempre existe a preocupação com a qualidade. Quando trabalhamos em equipe, essa preocupação se torna ainda mais presente, pois são várias pessoas produzindo código, cada uma ao seu estilo.

Para melhorar um pouco esse cenário já conhecido, temos ferramentas que nos auxiliam a manter o código em um nível adequado de qualidade, em diversos aspectos. Nesta série que começamos hoje, vamos conhecer ferramentas que podem nos auxiliar a manter nosso código Android mais adequado.

Começando, vamos conhecer o Checkstyle. Conforme citado anteriormente, principalmente quando trabalhamos em um projeto com mais de uma pessoa, o código tende a adquirir traços da “personalidade” de cada um, seja através de indentação com tabs / espaços, posicionamento da chave, e até nomenclatura de classes e atributos. O Checkstyle tem por objetivo auxiliar a manter um padrão de código por todo o projeto, apontando trechos que estejam fugindo do padrão configurado.

O mais interessante, nesse caso, é que o Gradle, o nosso querido build system do Android, já possui o Checkstyle integrado ao projeto, necessitando apenas uma pequena configuração para que ele seja executado.

Bom, para começarmos, primeiramente precisamos aplicar o plugin doCheckstyle no nosso arquivo build.gradle.

apply plugin: 'checkstyle'

Uma prática que geralmente adoto nessa configuração, é adicionar o Checkstyle a task check do Gradle. Assim, além das demais verificações que já possuímos (como a execução do Lint), teremos também o Checkstylerodando.

check.dependsOn 'checkstyle'

Feito isso, vamos configurar a execução dessa task em nosso projeto.

task checkstyle(type: Checkstyle) {
    configFile file("$project.rootDir/config/checkstyle/checkstyle.xml")
    source 'src'
    include '**/*.java'
    classpath = files()
}

Nessa configuração, temos primeiramente a propriedade configFile que recebe o arquivo checkstyle.xml que é quem define o estilo do nosso projeto (já já veremos como esse arquivo é). Posteriormente, configuramos para que a execução seja feita sobre a nossa pasta source, incluindo todos os arquivos .java, e concluímos com a configuração do classpath, exigida pelo plugin. Vamos conhecer então o arquivo checkstyle.xml.

Esse arquivo é que conterá as regras a serem validadas pelo CheckStyle. Para esse primeiro exemplo, vamos adicionar apenas uma, que validará se não existem espaços entre os símbolos < e > na declaração de generics.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Puppy Crawl//DTD Check Configuration 1.3//EN" "http://www.puppycrawl.com/dtds/configuration_1_3.dtd">
<module name="Checker">

    <module name="TreeWalker">
        <module name="GenericWhitespace" />
    </module>

</module>

Existe uma infinidade de regras que podem ser adicionadas ao arquivo. Todas elas podem ser encontradas na documentação oficial, e podem ser aplicadas de acordo com o estilo a ser utilizado em seu projeto.

Para validar que a regra está funcionando, podemos criar uma classe simples, que viole a regra de estilo especificada:

package net.rafaeltoledo.codequality;

import android.support.v7.app.AppCompatActivity;
import java.util.List;

public class MyActivity extends AppCompatActivity {

    List< String > myList;
}

Executando a task checkstyle através do Gradle (pela linha de comando ou pelo menu Gradle, geralmente localizado na barra direita do Android Studio), teremos uma mensagem ao final da execução:

Executing external task ‘checkstyle’…
Parallel execution is an incubating feature.
[ant:checkstyle] [...]MyActivity.java:9:10: ‘<’ é seguido de espaço em branco. [ant:checkstyle] [...]MyActivity.java:9:17: ‘>’ é precedido por espaço em branco.

:app:checkstyle FAILED

FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ‘:app:checkstyle’.
> Checkstyle rule violations were found. See the report at: file:///[...]/app/build/reports/checkstyle/checkstyle.xml

* Try:
Run with — stacktrace option to get the stack trace. Run with — info or — debug option to get more log output.

BUILD FAILED

Total time: 1.803 secs

Além de reportar os problemas no console, ele ainda gera um relatório XML com todas as violações das regras!

Corrigindo o nosso código para:

List<String> myList;

Temos uma execução tranquila e sem erros 🙂

Executing external task ‘checkstyle’…
Parallel execution is an incubating feature.
:app:checkstyle

BUILD SUCCESSFUL

Total time: 2.622 secs

E é isso! No próximo post vamos conhecer a FindBugs, que pode nos salvar de bugs clássicos e problemas de segurança no nosso código 😀

Até lá!

Deixe uma resposta