streamalism.org

1. Oversigt

Checkstyle er et open source-værktøj, der kontrollerer kode i forhold til et konfigurerbart sæt regler.

I denne vejledning skal vi se på hvordan man integrerer Checkstyle i et Java-projekt via Maven og ved hjælp af IDE-plugins.

Plugins nævnt i nedenstående sektioner er ikke afhængige af hinanden og kan integreres individuelt i vores build eller IDE'er. For eksempel er Maven-pluginet ikke nødvendigt i vores pom.xml at køre valideringerne i vores Eclipse IDE.

2. Checkstyle Maven-plugin

2.1. Maven-konfiguration

For at tilføje Checkstyle til et projekt skal vi tilføje pluginet i rapporteringsafsnittet i a pom.xml:

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

Dette plugin leveres med to foruddefinerede checks, en Sun-stil check og en Google-stil check. Standardkontrol for et projekt er sun_checks.xml.

For at bruge vores brugerdefinerede konfiguration kan vi specificere vores konfigurationsfil som vist i eksemplet ovenfor. Ved hjælp af denne konfiguration læser pluginet nu vores brugerdefinerede konfiguration i stedet for den medfølgende standard.

Den seneste version af pluginet kan findes på Maven Central.

2.2. Rapportgenerering

Nu hvor vores Maven-plugin er konfigureret, kan vi generere en rapport til vores kode ved at køre mvn websted kommando. Når build er færdig, er rapporten tilgængelig i mål / sted mappe under navnet checkstyle.html.

Der er tre hoveddele i en Checkstyle-rapport:

Filer: Dette afsnit af rapporten giver os listen over filer, hvor overtrædelserne er sket. Det viser os også antallet af overtrædelser mod deres sværhedsgrad. Sådan ser rapportens filsektion ud:

Regler: Denne del af rapporten giver os en oversigt over de regler, der blev brugt til at kontrollere for overtrædelser. Det viser kategorien af ​​reglerne, antallet af overtrædelser og sværhedsgraden af ​​disse overtrædelser. Her er et eksempel på rapporten, der viser regelsektionen:

Detaljer: Endelig giver detaljeringsafsnittet i rapporten os detaljer om de overtrædelser, der er sket. De angivne detaljer er på linjenummerniveau. Her er et eksempeldetaljer i rapporten:

2.3. Byg integration

Hvis der er behov for strenge kontroller af kodestilen, Vi kan konfigurere pluginet på en sådan måde, at build mislykkes, når koden ikke overholder standarderne.

Vi gør dette ved at tilføje et eksekveringsmål til vores plugin-definition:

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

Det configLocation attribut definerer, hvilken konfigurationsfil der skal henvises til for valideringerne.

I vores tilfælde er konfigurationsfilen checkstyle.xml. Målet kontrollere nævnt i eksekveringsafsnittet beder pluginet om at køre i kontrolfasen af ​​buildet og tvinger en buildfejl, når der opstår en overtrædelse af kodningsstandarder.

Nu, hvis vi kører mvn ren installation kommando, det scanner filerne for overtrædelser, og build mislykkes, hvis der findes nogen overtrædelser.

Vi kan også kun køre kontrollere mål for pluginet ved hjælp af mvn checkstyle: check, uden at konfigurere udførelsesmålet. At køre dette trin vil også resultere i en byggefejl, hvis der er valideringsfejl.

3. Eclipse-plugin

3.1. Konfigurationer

Ligesom med Maven-integrationen giver Eclipse os mulighed for at bruge vores brugerdefinerede konfiguration.

For at importere vores konfiguration skal du gå til Vindue -> Indstillinger -> Checkstyle. Ved Globale kontrolkonfigurationer sektion, klik på Ny.

Dette åbner en dialog, der giver os muligheder for at specificere vores brugerdefinerede konfigurationsfil.

3.2. Rapporter browsing

Nu hvor vores plugin er konfigureret, kan vi bruge det til at analysere vores kode.

For at kontrollere kodestil for et projekt skal du højreklikke på projektet i Eclipse Project Explorer og vælg CheckStyle -> Tjek kode med Checkstyle.

Pluginet giver os feedback på vores Java-kode i Eclipse, teksteditor. Det genererer også overtrædelsesrapporten for projektet, som er tilgængelig som en visning i Eclipse.

Gå til for at se rapporten om overtrædelse Vindue -> Vis visning -> Andet, og søg efter Checkstyle. Indstillinger for Overtrædelser og Overtrædelsesdiagram skal vises.

Valg af en af ​​indstillingerne giver os en repræsentation af overtrædelser grupperet efter type. Her er overtrædelsesdiagrammet for et prøveprojekt:

Hvis du klikker på et afsnit af cirkeldiagrammet, kommer vi til listen over faktiske overtrædelser i koden.

Alternativt kan vi åbne Problem visning af Eclipse IDE og kontroller de problemer, der er rapporteret af pluginet.

Her er et eksempel på en problemvisning af formørkelse-IDE:

Klik på en af ​​advarslerne fører os til koden, hvor overtrædelsen er sket.

4. IntelliJ IDEA-plugin

4.1. Konfiguration

Ligesom Eclipse giver IntelliJ IDEA os også mulighed for at bruge vores egne brugerdefinerede konfigurationer med et projekt.

I IDE åbner du Indstillinger og søger efter Checkstyle. Der vises et vindue, der har mulighed for at vælge vores checks. Klik på + knappen, og et vindue åbnes, som giver os mulighed for at specificere placeringen af ​​den fil, der skal bruges.

Nu vælger vi en konfigurations-XML-fil og klikker på Næste. Dette åbner det forrige vindue og viser vores nyligt tilføjede tilpassede konfigurationsindstilling. Vi vælger den nye konfiguration og klikker på OK for at begynde at bruge den i vores projekt.

4.2. Rapporter browsing

Nu hvor vores plugin er konfigureret, lad os bruge det til at kontrollere for overtrædelser. Gå til for at kontrollere for overtrædelser af et bestemt projekt Analyser -> Undersøg kode.

Inspektionsresultaterne giver os et overblik over overtrædelserne i afsnittet Checkstyle. Her er en eksempelrapport:

Klik på overtrædelserne fører os til de nøjagtige linjer i filen, hvor overtrædelserne er sket.

5. Konfiguration af brugerdefineret checkstyle

I Maven-rapportgenereringsafsnittet (afsnit 2.2) brugte vi en brugerdefineret konfigurationsfil til at udføre vores egne kodningsstandardkontrol.

Vi har en måde at oprette vores egen tilpassede XML-fil på hvis vi ikke ønsker at bruge den pakkede Google- eller Sun-kontrol.

Her er den brugerdefinerede konfigurationsfil, der bruges til ovenstående kontrol:

5.1. DOCTYPE Definition

Den første linje i dvs. DOCTYPE-definitionen er en vigtig del af filen, og den fortæller, hvor DTD'en skal downloades fra, så konfigurationerne kan forstås af systemet.

Hvis vi ikke inkluderer denne definition i vores konfigurationsfil, er den ikke en gyldig konfigurationsfil.

5.2. Moduler

En konfigurationsfil er primært sammensat af moduler. Et modul har en attribut navn hvilket repræsenterer hvad modulet gør. Værdien af navn attribut svarer til en klasse i plugins kode, der udføres, når plugin køres.

Lad os lære om de forskellige moduler, der findes i konfigurationen ovenfor.

5.3. Moduloplysninger

• Checker: Moduler er struktureret i et træ, der har Checker-modulet ved roden. Dette modul definerer de egenskaber, der arves af alle andre konfigurationsmoduler.
• TreeWalker: Dette modul kontrollerer de enkelte Java-kildefiler og definerer egenskaber, der gælder for kontrol af sådanne filer.
• Undgå StarImport: Dette modul sætter en standard for ikke at bruge Star-import i vores Java-kode. Det har også en egenskab, der beder pluginet om at rapportere sværhedsgraden af ​​sådanne problemer som en advarsel. Når sådanne overtrædelser findes i koden, vil der således blive markeret en advarsel mod dem.

For at læse mere om tilpassede konfigurationer, følg dette link.

6. Rapportanalyse for Spring-Rest-projektet

I dette afsnit vil vi kaste lys over en analyse foretaget af Checkstyle ved hjælp af den brugerdefinerede konfiguration oprettet i afsnit 5 ovenfor på det fjederhvile-projekt, der er tilgængeligt på GitHub som et eksempel.

6.1. Generering af overtrædelsesrapporter

Vi har importeret konfigurationen til Eclipse IDE, og her er den overtrædelsesrapport, der genereres til projektet:

Advarslerne rapporteret her siger, at import af jokertegn skal undgås i koden. Vi har to filer, der ikke overholder denne standard. Når vi klikker på advarslen, fører det os til Java-filen, der har overtrædelsen.

Her er hvordan HeavyResourceController.java filen viser den rapporterede advarsel:

6.2. Problemløsning

Brug af Star-import er generelt ikke en god praksis, da det kan skabe konflikter, når to eller flere pakker indeholder den samme klasse.

Overvej klassen som et eksempel Liste, hvilken er fås i pakker java.util og java.awt begge. Hvis vi bruger både import af java.util . * og java.awt. * vores kompilator undlader at kompilere koden, som Liste fås i begge pakker.

For at løse problemet nævnt ovenfor organiserer vi importen i begge filer og gemmer dem. Nu når vi kører pluginet igen, ser vi ikke overtrædelserne, og vores kode følger nu de standarder, der er angivet i vores brugerdefinerede konfiguration.

7. Konklusion

I denne artikel har vi dækket det grundlæggende for at integrere Checkstyle i vores Java-projekt.

Vi har lært, at det er et simpelt, men alligevel kraftfuldt værktøj, der bruges til at sikre, at udviklere overholder de kodningsstandarder, som organisationen har sat.

Eksempelkoden, vi brugte til statisk analyse, er tilgængelig på GitHub.