Introduzione a CheckStyle

1. Panoramica

Checkstyle è uno strumento open source che verifica il codice rispetto a un insieme di regole configurabile.

In questo tutorial, vedremo come integrare Checkstyle in un progetto Java tramite Maven e utilizzando i plugin IDE.

I plugin menzionati nelle sezioni seguenti non dipendono l'uno dall'altro e possono essere integrati individualmente nella nostra build o nei nostri IDE. Ad esempio, il plug-in Maven non è necessario nel nostro pom.xml per eseguire le convalide nel nostro IDE Eclipse.

2. Plugin Checkstyle Maven

2.1. Configurazione Maven

Per aggiungere Checkstyle a un progetto, dobbiamo aggiungere il plugin nella sezione dei rapporti di un pom.xml :

   org.apache.maven.plugins maven-checkstyle-plugin 3.0.0  checkstyle.xml    

Questo plugin viene fornito con due controlli predefiniti, un controllo in stile Sun e un controllo in stile Google . Il controllo predefinito per un progetto è sun_checks.xml.

Per utilizzare la nostra configurazione personalizzata, possiamo specificare il nostro file di configurazione come mostrato nell'esempio sopra. Usando questa configurazione, il plugin ora leggerà la nostra configurazione personalizzata invece di quella predefinita fornita.

L'ultima versione del plugin può essere trovata su Maven Central.

2.2. Generazione di report

Ora che il nostro plugin Maven è configurato, possiamo generare un report per il nostro codice eseguendo il comando mvn site . Al termine della compilazione, il report è disponibile nella cartella target / site con il nome checkstyle.html.

Ci sono tre parti principali in un rapporto Checkstyle:

File: questa sezione del rapporto ci fornisce l'elenco dei file in cui si sono verificate le violazioni . Ci mostra anche il conteggio delle violazioni rispetto ai loro livelli di gravità. Ecco come appare la sezione dei file del rapporto:

Regole: questa parte del rapporto fornisce una panoramica delle regole utilizzate per verificare le violazioni . Mostra la categoria delle regole, il numero di violazioni e la gravità di tali violazioni. Ecco un esempio del report che mostra la sezione delle regole:

Dettagli: Infine, la sezione dei dettagli del rapporto ci fornisce i dettagli delle violazioni che si sono verificate . I dettagli forniti sono a livello di numero di riga. Ecco una sezione dei dettagli di esempio del rapporto:

2.3. Build Integration

Se è necessario disporre di controlli rigorosi sullo stile di codifica, possiamo configurare il plugin in modo tale che la compilazione fallisca quando il codice non aderisce agli standard.

Lo facciamo aggiungendo un obiettivo di esecuzione alla nostra definizione di plugin:

 org.apache.maven.plugins maven-checkstyle-plugin ${checkstyle-maven-plugin.version}  checkstyle.xml     check    

L' attributo configLocation definisce il file di configurazione a cui fare riferimento per le convalide.

Nel nostro caso, il file di configurazione è checkstyle.xml. Il controllo degli obiettivi menzionato nella sezione di esecuzione chiede al plugin di essere eseguito nella fase di verifica della build e forza un errore di compilazione quando si verifica una violazione degli standard di codifica.

Ora, se eseguiamo il comando mvn clean install , analizzerà i file per le violazioni e la compilazione fallirà se vengono rilevate violazioni.

Possiamo anche eseguire solo l' obiettivo di controllo del plugin utilizzando mvn checkstyle: check, senza configurare l'obiettivo di esecuzione. L'esecuzione di questo passaggio comporterà anche un errore di compilazione se sono presenti errori di convalida.

3. Plugin Eclipse

3.1. Configurazioni

Proprio come con l'integrazione di Maven, Eclipse ci consente di utilizzare la nostra configurazione personalizzata.

Per importare la nostra configurazione, vai su Finestra -> Preferenze -> Stile di controllo. Nella sezione Configurazioni controllo globale , fare clic su Nuovo.

Questo aprirà una finestra di dialogo che ci fornirà le opzioni per specificare il nostro file di configurazione personalizzato.

3.2. Navigazione rapporti

Ora che il nostro plugin è configurato possiamo usarlo per analizzare il nostro codice.

Per controllare lo stile di codifica per un progetto, fare clic con il pulsante destro del mouse sul progetto in Eclipse Project Explorer e selezionare CheckStyle -> Check Code with Checkstyle.

Il plugin ci fornirà feedback sul nostro codice Java all'interno di Eclipse, editor di testo. Genererà anche il rapporto di violazione per il progetto che è disponibile come vista in Eclipse.

Per visualizzare la segnalazione di violazione, vai a Finestra -> Mostra vista -> Altro e cerca Stile di controllo. Dovrebbero essere visualizzate le opzioni per le violazioni e il grafico delle violazioni .

La selezione di una delle due opzioni ci darà una rappresentazione delle violazioni raggruppate per tipo. Ecco il grafico a torta di violazione per un progetto di esempio:

Fare clic su una sezione del grafico a torta ci porterebbe all'elenco delle violazioni effettive nel codice.

In alternativa, possiamo aprire la vista Problem dell'IDE Eclipse e controllare i problemi segnalati dal plugin.

Di seguito è riportato un esempio di visualizzazione dei problemi dell'IDE Eclipse:

Facendo clic su uno qualsiasi degli avvisi, ci porterà al codice in cui si è verificata la violazione.

4. Plugin IntelliJ IDEA

4.1. Configurazione

Come Eclipse, anche IntelliJ IDEA ci consente di utilizzare le nostre configurazioni personalizzate con un progetto.

Nell'IDE, apri Impostazioni e cerca Checkstyle. Viene visualizzata una finestra che ha la possibilità di selezionare i nostri controlli. Fare clic sul pulsante + e si aprirà una finestra che ci permetterà di specificare la posizione del file da utilizzare.

Ora selezioniamo un file XML di configurazione e facciamo clic su Avanti. Questo aprirà la finestra precedente e mostrerà la nostra opzione di configurazione personalizzata appena aggiunta. Selezioniamo la nuova configurazione e facciamo clic su OK per iniziare a usarla nel nostro progetto.

4.2. Navigazione rapporti

Ora che il nostro plugin è configurato, usiamolo per verificare le violazioni. Per verificare la presenza di violazioni di un particolare progetto, vai su Analizza -> Controlla codice.

I risultati delle ispezioni ci daranno una visione delle violazioni nella sezione Stile di controllo. Ecco un rapporto di esempio:

Facendo clic sulle violazioni ci porterà alle righe esatte del file in cui si sono verificate le violazioni.

5. Configurazione personalizzata dello stile di controllo

Nella sezione relativa alla generazione di rapporti Maven (Sezione 2.2), abbiamo utilizzato un file di configurazione personalizzato per eseguire i nostri controlli standard di codifica.

Abbiamo un modo per creare il nostro file XML di configurazione personalizzato se non vogliamo utilizzare i controlli Google o Sun in pacchetto.

Ecco il file di configurazione personalizzato utilizzato per i controlli precedenti:

5.1. DOCTYPE Definizione

La prima riga della definizione ad esempio DOCTYPE è una parte importante del file e indica da dove scaricare il DTD in modo che le configurazioni possano essere comprese dal sistema.

Se non includiamo questa definizione nel nostro file di configurazione non sarà un file di configurazione valido.

5.2. Moduli

Un file di configurazione è composto principalmente da moduli. Un modulo ha un nome di attributo che rappresenta ciò che fa il modulo. Il valore dell'attributo name corrisponde a una classe nel codice del plugin che viene eseguita quando il plugin viene eseguito.

Impariamo a conoscere i diversi moduli presenti nella configurazione sopra.

5.3. Dettagli del modulo

  • Checker: i moduli sono strutturati in un albero che ha il modulo Checker alla radice. Questo modulo definisce le proprietà ereditate da tutti gli altri moduli della configurazione.
  • TreeWalker: questo modulo controlla i singoli file di origine Java e definisce le proprietà applicabili al controllo di tali file.
  • EvitareStarImport: questo modulo definisce uno standard per non utilizzare le importazioni Star nel nostro codice Java. Ha anche una proprietà che chiede al plugin di segnalare la gravità di tali problemi come avviso. Pertanto, ogni volta che tali violazioni vengono rilevate nel codice, verrà contrassegnato un avviso contro di esse.

Per saperne di più sulle configurazioni personalizzate segui questo link.

6. Analisi del report per il progetto Spring-Rest

In questa sezione, faremo luce su un'analisi fatta da Checkstyle, utilizzando la configurazione personalizzata creata nella sezione 5 sopra, sul progetto di molleggio disponibile su GitHub come esempio.

6.1. Generazione del rapporto di violazione

Abbiamo importato la configurazione nell'IDE Eclipse ed ecco il rapporto di violazione generato per il progetto:

Gli avvisi qui riportati dicono che le importazioni di caratteri jolly dovrebbero essere evitate nel codice. Abbiamo due file che non rispettano questo standard. Quando facciamo clic sull'avviso, ci porta al file Java che presenta la violazione.

Ecco come il file HeavyResourceController.java mostra l'avviso riportato:

6.2. Risoluzione dei problemi

L'uso di Star imports non è una buona pratica in generale in quanto può creare conflitti quando due o più pacchetti contengono la stessa classe.

A titolo di esempio, si consideri la classe List, che è disponibile in pacchetti java.util e java.awt entrambi. Se usiamo entrambe le importazioni di java.util . * E java.awt. * Il nostro compilatore non riuscirà a compilare il codice, poiché List è disponibile in entrambi i pacchetti.

Per risolvere il problema sopra menzionato, organizziamo le importazioni in entrambi i file e li salviamo. Ora, quando eseguiamo nuovamente il plug-in, non vediamo le violazioni e il nostro codice ora segue gli standard impostati nella nostra configurazione personalizzata.

7. Conclusione

In questo articolo, abbiamo trattato le basi per l'integrazione di Checkstyle nel nostro progetto Java.

Abbiamo appreso che si tratta di uno strumento semplice ma potente utilizzato per garantire che gli sviluppatori aderiscano agli standard di codifica stabiliti dall'organizzazione.

Il codice di esempio che abbiamo utilizzato per l'analisi statica è disponibile su GitHub.