Sempre que começamos a escrever código, por mais simples ou complexo que seja, 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 por meio 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 é que o Gradle, o nosso querido build system do Android, já possui o Checkstyle integrado ao projeto; logo, necessitamos apenas de uma pequena configuração para que ele seja executado.

Para começarmos, 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 à 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 Checkstyle rodando.

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, por sua vez, é 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 esteja 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 por meio 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 artigo vamos conhecer a FindBugs, que pode nos salvar debugs clássicos e problemas de segurança no nosso código.

Ficou alguma dúvida ou tem alguma observação? Aproveite os campos abaixo. Até a próxima!

***

Artigo originalmente publicado no blog e no Medium pessoal do autor.