Aplicando code style em projetos Java com Checkstyle

Introdução

Dentro de um time de desenvolvimento é essencial seguir padrões, o que não é diferente para o código fonte. Existem inúmeros padrões existentes, mesmo dentro da mesma linguagem de programação, com foco em redibilidade, manutenebilidade e até em preferências do próprio time, por que não? As possibilidades são muitas; desde separação de imports em grupos, tipo de identação com tabs ou espaços, alinhamento dos else, if, tamanho máximo da linha, nomes de variáveis locais, nome de métodos; até “erros” mesmo com falta de nova linha no final de arquivo.

Motivação

Com intuito de organizar todas estas possibilidades, alguns grandes da indústria definiram seus padrões, como Google e Spring. No entanto, garantir estes padrões manualmente, em tempo de review, é uma tarefa chata, além de disperdiçar o tempo e a atenção do time para o que realmente importa, a funcionalidade/código desenvolvido. 

Que tal se esta tarefa chata, mas importante, for feita de forma automatizada, integrado ao build, ou mesmo pela IDE, garantindo que o código do Pull Request no GitHub já esteja totalmente dentro dos padrões? É justamente isso que o Checkstyle proporciona.

Trata-se de uma ferramenta altamente configurável para garantir padrões de códigos, tanto de design de classes, métodos, layout de código, formatação, etc.

Configuração (checkstyle.xml)

O Checkstyle é baseado em regras, definidas no arquivo de configuração checkstyle.xml, que podem ser adicionadas conforme as definições do time de desenvolvimento. Além disso, pode-se usar arquivos com padrões pré-definidos já bem difundidos na comunidade, listados na página do Checkstyle.

Abaixo, seguem algumas das centenas de regras disponíveis:

• Nova linha no final do arquivo
• Tamanho da linha
• Indentação com tabs ou espaços
• Imports não usados
• Espaços em branco
• Nome de variável local
• Nome de constante
• Nome de método

Existem situações onde as regras não se aplicam, como classes estáticas de início de uma aplicação Spring Boot, ou classes de teste. Nestes casos, pode-se adicionar exceções às regras através das supressions.

Integração ao build (maven)

Uma ótima opção para garantir que o pull request já vai estar dentro dos padrões é integrar as verificações do Checkstyle ao build. Caso alguma violação ocorra, o buil falha. Assim, os padrões são garantidos independente de IDE.

Seguem algumas considerações da configuração listada abaixo:

• As verificações estão configuradas para ocorrer na fase de validate do maven, portanto esta nova etapa vai acontecer em comandos comuns, como mvn clean package ou mvn clean install (acesse aqui para mais detalhes do maven).

• É possível configurar o plugin para não quebrar o build, sendo normalmente mostradas as violações, porém seguindo as próximas etapas de construção do artefato, execução de testes, etc. Esta configuração pode ser interessante para uma adoção gradativa em projetos legados grandes.

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-checkstyle-plugin</artifactId>
	<version>3.1.2</version>
	<dependencies>
		<dependency>
			<groupId>com.puppycrawl.tools</groupId>
			<artifactId>checkstyle</artifactId>
			<version>8.45</version>
		</dependency>
	</dependencies>
	<executions>
		<execution>
			<id>validate</id>
			<phase>validate</phase>
			<configuration>
				<configLocation>checkstyle.xml</configLocation>
				<encoding>UTF-8</encoding>
				<consoleOutput>true</consoleOutput>
				<failsOnError>true</failsOnError>
				<failOnViolation>true</failOnViolation>
			</configuration>
			<goals>
				<goal>check</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Plugin para IDE

É possível ainda utilizar plugins para sua IDE e ter feedbacks ainda mais integrados e rápidos sobre os seus padrões. No caso do Intellij, o plugin encontra-se aqui. Abaixo, há um screenshot da aba do plugin na IDE com os erros reportados, onde pode-se clicar e ir direto para a linha do erro, facilitando a navegação.

Conclusão

O Checkstyle é uma ferramenta muito poderosa e flexível para garantir padrões de código. A flexibilidade vai tão longe que é possível criar regrar próprias como nomes de variáveis com determinado padrão seguido pela empresa, ou banir bibliotecas deprecadas dos projetos, como JUnit 4, forçando o time a usar o JUnit 5.

Recomendo fortemente o uso, aliado à correta configuração de Code Style da IDE, o que faz com que o Checkstyle seja apenas uma checagem final, removendo esta responsabilidade do revisor.

Ainda tem dúvidas? Tem sugestões? Escreva nos comentários. Até a próxima.