Spotless — Como integrar Java style checker com Gradle

Qualquer tolo pode escrever código que um computador entenda. Bons programadores escrevem código que as pessoas possam entender.

- Martin Fowler

Essa afirmação de Martin Fowler é simples e clara, no entanto, traz um impacto profundo no processo de desenvolvimento de software. O código que as pessoas desenvolvem são feitos por pessoas para pessoas, não são códigos feitos por pessoas para computadores.

Através dessa perspectiva, livros foram escritos, técnicas e disciplinas foram criadas para melhorar a qualidade do código escrito — o famoso código limpo. O desenvolvimento guiado por testes (Test Driven Development — TDD), a técnica de refactoring, o livro Clean Code, são alguns exemplos de ferramentas que auxiliam a vida das pessoas que desenvolvem.

Formatação

Um dos tópicos do livro Clean Code, é a formatação do código-fonte. Profissionais de software devem ter em mente que os seus códigos têm que estar formatados e que a formatação de código é tão importante quanto às outras técnicas.

EmpresasService.java — bagunçado

O código anterior e o código seguinte são equivalentes, onde a única diferença entre eles é a formatação. Qual dos dois é mas fácil de ler?

EmpresasService.java formatado

Acordos de equipe

Por ser uma prática importante no desenvolvimento de software e cada pessoa ter o seu próprio estilo de formatação, é necessário antes de escrever a primeira linha de código do projeto, definir qual será a formatação do código-fonte (caso a empresa não tenha um padrão) e garantir que ela seja seguida.

Aí é onde entra em cena as ferramentas de automação de build e os seus ecossistemas de plugins que garantem a formatação do código durante a compilação do código-fonte. Neste artigo vamos ver um passo a passo para integração do plugin de formatação de código Spotless integrado com o multi-module do Gradle.

1. Definir qual vai ser o estilo de formatação
2. Configurar o arquivo de formatação de acordo com a IDE (Neste artigo vai ser mostrado para o Eclipse e o IntelliJ)
3. Criar um projeto multi-module no Gradle
4. Configurar o plugin do Spotless no arquivo de build

Tutorial

1. Definir qual vai ser o estilo de formatação

Tanto o Eclipse como o IntelliJ utilizam arquivos .xml para importar e exportar as regras de formatação do código-fonte. Portanto, um bom ponto de partida é sentar com a equipe e customizar os estilos de formatação que já vêm pré definidos nessas IDEs.

2. Configurar o estilo de formatação

Após configurar o estilo de formatação, é necessário importá-lo nas IDEs dos desenvolvedores, esse passo pode ser opcional, pois, o plugin Gradle tem uma tarefa (task) que formata o código-fonte. No entanto, apesar de ser opcional, é importante que seja realizado, pois, o desenvolvedor pode aproveitar os recursos da IDE de formatar o código.

Eclipse

Eclipse -> Preferences -> Java -> Code Style -> Formatter -> Import

IntelliJ

IntelliJ IDEA -> Preferences -> Editor -> Code Style -> Java -> Ícone da engrenagem -> Import Schema -> Eclipse XML Profile

3. Criar um projeto multi-module Gradle

1. gradle init
2. Selecionar o tipo de projeto application
3. Selecionar a linguagem de implementação Java
4. Selecionar yes para dividir as funcionalidades entre sub projetos
5. Selecionar a DSL Groovy
6. Dar um nome ao projeto
7. Nomear o pacote

4. Configurar o plugin do Spotless

• Depois de ter criado o projeto multi-module no Gradle, criar o arquivo build.gradle na raiz do projeto.
• Criar uma pasta para o arquivo de formatação .xml dentro do projeto raiz e importar o arquivo de formatação. A estrutura de pastas e arquivos deve ser semelhante a figura seguinte.

Estruturas de pastas e arquivos

• Configurar o plugin Spotless para todos os sub projetos. A continuação a configuração do arquivo build.gradle da raiz projeto.

build.gradle

Depois de configurado, o processo de compilação falhará caso o código-fonte não esteja de acordo com as regras criadas no arquivo .xml. Além disso, duas tarefas (tasks) do Gradle estarão disponíveis para formatar e verificar a formatação através da linha de comando.

• gradle spotlessApply
• gradle spotlessCheck

A leitura de um código-fonte deveria ser semelhante a de um livro. Pois, no final das contas, estamos lendo textos (ou instruções que a máquina entende) que devem fazer sentido para as pessoas que vão trabalhar nesse código-fonte, ou seja, as pessoas desenvolvedoras.

No segmento de conteúdos (websites, blogs, revistas, jornais), existem profissionais que fazem a diagramação que servem para distribuir e organizar os elementos (imagens e textos) visando facilitar o entendimento do conteúdo apresentado.

Você já imaginou cada página de um livro ter uma diagramação completamente diferente? Já imaginou dentro de uma mesma página ter mais de uma diagramação? Como você se sentiria lendo este livro? Qual seria a complexidade de entendimento do conteúdo apresentado?

As mesmas respostas das perguntas anteriores deveriam ser aplicadas na leitura do código-fonte. Além dessas perguntas, acrescentaria mais algumas relacionadas ao contexto de software:

1. Gostaria de a cada projeto, dentro da empresa, ter que mudar a formatação do código-fonte de acordo com as escolhas da equipe ou em muitos casos do líder técnico?
2. Seria válido criar uma formatação padrão de código para o departamento da empresa? Isso facilitaria a leitura do código-fonte entre os diversos projetos existentes ou deixaria inflexível e tiraria a autonomia dos times?

diogopeixoto/code-formatter-spotless