Introdução ao CheckStyle

Para adicionar Checkstyle a um projeto, precisamos adicionar o plugin na seção de relatórios de umpom.xml:

This plugin comes with two predefined checks, a Sun-style check, and a Google-style check. A verificação padrão para um projeto ésun_checks.xml.

Para usar nossa configuração personalizada, podemos especificar nosso arquivo de configuração, como mostrado na amostra acima. Usando essa configuração, o plug-in agora lerá nossa configuração personalizada, em vez da padrão fornecida.

A última versão do plugin pode ser encontrada emMaven Central.

Agora que nosso plugin Maven está configurado, podemos gerar um relatório para nosso código executando o comandomvn site. Once the build finishes, the report is available in the target/site folder under the name checkstyle.html.

Existem três partes principais em um relatório do Checkstyle:

Files: Esta seção do relatório nos fornecethe list of files in which the violations have happened. Também nos mostra a contagem das violações contra seus níveis de gravidade. Aqui está a aparência da seção de arquivos do relatório:

Rules: Esta parte do relatório nos dá umoverview of the rules that were used to check for violations. Ele mostra a categoria das regras, o número de violações e a gravidade dessas violações. Aqui está uma amostra do relatório que mostra a seção de regras:

Details: Finalmente, a seção de detalhes do relatório nos fornecedetails of the violations that have happened. Os detalhes fornecidos estão no nível do número da linha. Aqui está uma seção de detalhes de amostra do relatório:

Se houver necessidade de verificações rigorosas no estilo de codificação,we can configure the plugin in such a way that the build fails when the code doesn’t adhere to the standards.

Fazemos isso adicionando uma meta de execução à nossa definição de plug-in:

O atributoconfigLocation define a qual arquivo de configuração se referir para as validações.

Em nosso caso, o arquivo de configuração écheckstyle.xml. O objetivocheck mencionado na seção de execução solicita que o plugin seja executado na fase de verificação da construção e força uma falha de construção quando ocorre uma violação dos padrões de codificação.

Agora, se executarmos o comandomvn clean install, ele verificará os arquivos em busca de violações e a compilação falhará se quaisquer violações forem encontradas.

Também podemos executar apenas a metacheck do plugin usandomvn checkstyle:check, sem configurar a meta de execução. A execução desta etapa resultará em uma falha de compilação também se houver algum erro de validação.

Assim como na integração com o Maven, o Eclipse nos permite usar nossa configuração personalizada.

Para importar nossa configuração, vá paraWindow → Preferences → Checkstyle. Na seçãoGlobal Check Configurations, clique emNew.

Isso abrirá um diálogo que fornecerá opções para especificar nosso arquivo de configuração personalizado.

Agora que nosso plugin está configurado, podemos usá-lo para analisar nosso código.

Para verificar o estilo de codificação de um projeto, clique com o botão direito do mouse no projeto emEclipse Project Explorere selecioneCheckStyle → Check Code with Checkstyle.

The plugin will give us feedback on our Java code within the Eclipse, text editor. Ele também irá gerar o relatório de violação para o projeto, que está disponível como uma visualização no Eclipse.

Para visualizar o relatório de violação, vá paraWindow → Show View → Other e pesquise por Checkstyle. As opções paraViolationseViolations Chart devem ser exibidas.

Selecionar uma das opções nos dará uma representação das violações agrupadas por tipo. Aqui está o gráfico de violações de um projeto de amostra:

Clicar em uma seção do gráfico de pizza nos levaria à lista de violações reais do código.

Como alternativa, podemos abrir a visualizaçãoProblem do Eclipse IDE e verificar os problemas relatados pelo plugin.

Aqui está uma amostra da Visualização de problemas do IDE Eclipse:

Clicar em qualquer um dos avisos nos levará ao código em que a violação ocorreu.

Como o Eclipse, o IntelliJ IDEA também nos permite usar nossas próprias configurações personalizadas em um projeto.

No IDE, abra Configurações e procure por Checkstyle. É exibida uma janela com a opção de selecionar nossas verificações. Clique no botão+ e se abrirá uma janela que permitirá especificar a localização do arquivo a ser utilizado.

Agora, selecionamos um arquivo XML de configuração e clique em Avançar. Isso abrirá a janela anterior e mostrará nossa opção de configuração personalizada recém-adicionada. Selecionamos a nova configuração e clicamos em OK para começar a usá-la em nosso projeto.

Agora que nosso plugin está configurado, vamos usá-lo para verificar se há violações. Para verificar se há violações de um projeto específico, vá paraAnalyze → Inspect Code.

The Inspections Results will give us a view of the violations under the Checkstyle section. Aqui está um relatório de amostra:

Clicar nas violações nos levará às linhas exatas no arquivo em que as violações ocorreram.

A primeira linha do i.e. a definição DOCTYPE é uma parte importante do arquivo e indica de onde baixar o DTD para que as configurações possam ser entendidas pelo sistema.

Se não incluirmos esta definição em nosso arquivo de configuração, não será um arquivo de configuração válido.

Um arquivo de configuração é composto principalmente por módulos. A module has an attribute name which represents what the module does. O valor do atributoname corresponde a uma classe no código do plugin que é executado quando o plugin é executado.

Vamos aprender sobre os diferentes módulos presentes na configuração acima.

Para ler mais sobre configurações personalizadas, siga estelink.

Importamos a configuração para Eclipse IDE e aqui está o relatório de violação gerado para o projeto:

Os avisos relatados aqui afirmam que as importações de caracteres curinga devem ser evitadas no código. Temos dois arquivos que não atendem a esse padrão. Quando clicamos no aviso, ele nos leva ao arquivo Java que possui a violação.

Veja como o arquivoHeavyResourceController.java mostra o aviso relatado:

O uso de importações Star não é uma boa prática em geral, pois pode criar conflitos quando dois ou mais pacotes contêm a mesma classe.

Como exemplo, considere a classeList, queis está disponível nos pacotesjava.utilejava.awt ambos. Se usarmos as importações dejava.util. * Ejava.awt.*, nosso compilador não conseguirá compilar o código, poisList está disponível em ambos os pacotes.

To resolve the issue mentioned above we organize the imports in both files and save them. Agora, quando executamos o plugin novamente, não vemos as violações e nosso código está seguindo os padrões definidos em nossa configuração personalizada.