streamalism.org

1. Oversikt

Checkstyle er et åpen kildekodeverktøy som sjekker koden mot et konfigurerbart sett med regler.

I denne opplæringen skal vi se på hvordan du integrerer Checkstyle i et Java-prosjekt via Maven og ved hjelp av IDE-plugins.

Plugins som er nevnt i avsnittene nedenfor, er ikke avhengige av hverandre og kan integreres individuelt i vår build eller IDE. For eksempel er ikke Maven-pluginet nødvendig i vårt pom.xml for å kjøre valideringene i vår formørkelse-IDE.

2. Checkstyle Maven Plugin

2.1. Maven-konfigurasjon

For å legge til Checkstyle i et prosjekt, må vi legge til pluginet i rapporteringsdelen av a pom.xml:

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

Dette pluginet leveres med to forhåndsdefinerte sjekker, en Sun-stil sjekk og en Google-stil sjekk. Standardkontrollen for et prosjekt er sun_checks.xml.

For å bruke vår tilpassede konfigurasjon kan vi spesifisere konfigurasjonsfilen vår som vist i eksemplet ovenfor. Ved hjelp av denne konfigurasjonen vil pluginet nå lese vår tilpassede konfigurasjon i stedet for den standard som er gitt.

Den siste versjonen av plugin-programmet finner du på Maven Central.

2.2. Rapportgenerering

Nå som Maven-pluginet vårt er konfigurert, kan vi generere en rapport for koden vår ved å kjøre mvn nettsted kommando. Når byggingen er ferdig, er rapporten tilgjengelig i mål / nettsted mappen under navnet checkstyle.html.

Det er tre hoveddeler i en Checkstyle-rapport:

Filer: Denne delen av rapporten gir oss listen over filer der bruddene har skjedd. Det viser oss også tellingen av bruddene mot alvorlighetsgraden. Slik ser filseksjonen ut i rapporten:

Regler: Denne delen av rapporten gir oss en oversikt over reglene som ble brukt til å kontrollere om det var brudd. Den viser kategorien av reglene, antall brudd og alvorlighetsgraden av disse bruddene. Her er et utvalg av rapporten som viser avsnittet om regler:

Detaljer: Til slutt gir detaljdelen av rapporten oss detaljer om bruddene som har skjedd. Detaljene som er gitt er på linjenummernivå. Her er en eksempeldetaljdel av rapporten:

2.3. Bygg integrasjon

Hvis det er behov for å ha strenge kontroller av kodestilen, vi kan konfigurere programtillegget på en slik måte at bygningen mislykkes når koden ikke overholder standardene.

Vi gjør dette ved å legge til et kjøringsmål i vår plugin-definisjon:

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

De configLocation attributt definerer hvilken konfigurasjonsfil du skal referere til for valideringene.

I vårt tilfelle er konfigurasjonsfilen checkstyle.xml. Målet Sjekk nevnt i kjøringsseksjonen ber plugin-programmet kjøre i verifiseringsfasen av bygningen og tvinger en byggefeil når det oppstår et brudd på kodingsstandarder.

Nå, hvis vi driver mvn ren installasjon kommandoen, vil den skanne filene for brudd, og build vil mislykkes hvis noen brudd blir funnet.

Vi kan også kjøre bare Sjekk målet for pluginet ved hjelp av mvn sjekkestil: sjekk, uten å konfigurere utførelsesmålet. Å kjøre dette trinnet vil også føre til en bygningsfeil hvis det er valideringsfeil.

3. Eclipse-plugin

3.1. Konfigurasjoner

Akkurat som med Maven-integrasjonen, gjør Eclipse oss i stand til å bruke vår tilpassede konfigurasjon.

For å importere konfigurasjonen vår, gå til Vindu -> Innstillinger -> Checkstyle. På Globale kontrollkonfigurasjoner delen, klikker du på Ny.

Dette åpner en dialog som gir oss muligheter til å spesifisere vår tilpassede konfigurasjonsfil.

3.2. Rapporter surfer

Nå som pluginet vårt er konfigurert, kan vi bruke det til å analysere koden vår.

For å sjekke kodestilen for et prosjekt, høyreklikker du prosjektet i Formørkelsesprosjektutforsker og velg CheckStyle -> Sjekk kode med Checkstyle.

Plugin vil gi oss tilbakemelding på Java-koden vår i Eclipse, teksteditor. Det vil også generere bruddrapporten for prosjektet som er tilgjengelig som visning i formørkelse.

Gå til for å se rapporten om brudd Vindu -> Vis visning -> Annet, og søk etter Checkstyle. Alternativer for Brudd og Brudddiagram skal vises.

Hvis du velger et av alternativene, vil vi representere brudd gruppert etter type. Her er bruddkartdiagrammet for et prøveprosjekt:

Hvis du klikker på en del av sektordiagrammet, kommer vi til listen over faktiske brudd på koden.

Alternativt kan vi åpne Problem visning av Eclipse IDE og sjekk problemene rapportert av pluginet.

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

Ved å klikke på en av advarslene vil vi ta oss til koden der bruddet har skjedd.

4. IntelliJ IDEA-plugin

4.1. Konfigurasjon

I likhet med Eclipse gjør IntelliJ IDEA oss også i stand til å bruke våre egne tilpassede konfigurasjoner med et prosjekt.

I IDE åpner du Innstillinger og søker etter Checkstyle. Det vises et vindu som har muligheten til å velge våre sjekker. Klikk på + -knappen og et vindu åpnes som lar oss spesifisere plasseringen til filen som skal brukes.

Nå velger vi en konfigurasjons-XML-fil og klikker på Neste. Dette åpner forrige vindu og viser vårt nylig lagt til tilpassede konfigurasjonsalternativ. Vi velger den nye konfigurasjonen og klikker på OK for å begynne å bruke den i prosjektet vårt.

4.2. Rapporter surfer

Nå som pluginet vårt er konfigurert, la oss bruke det til å se etter brudd. Gå til for å se etter brudd på et bestemt prosjekt Analyser -> Inspiser koden.

Inspeksjonsresultatene vil gi oss et syn på bruddene i Checkstyle-delen. Her er en eksempelrapport:

Ved å klikke på bruddene, kommer vi til de nøyaktige linjene i filen der bruddene har skjedd.

5. Egendefinert kontrollstilkonfigurasjon

I Maven-generering av seksjon (avsnitt 2.2) brukte vi en tilpasset konfigurasjonsfil for å utføre våre egne kodingsstandardkontroller.

Vi har en måte å lage vår egen tilpassede XML-fil for konfigurasjon hvis vi ikke vil bruke den pakkede Google- eller Sun-sjekken.

Her er den tilpassede konfigurasjonsfilen som brukes til kontrollene ovenfor:

5.1. DOCTYPE Definisjon

Den første linjen i dvs. DOCTYPE-definisjonen er en viktig del av filen, og den forteller hvor du skal laste ned DTD fra, slik at konfigurasjonene kan forstås av systemet.

Hvis vi ikke inkluderer denne definisjonen i konfigurasjonsfilen vår, vil ikke den være en gyldig konfigurasjonsfil.

5.2. Moduler

En konfigurasjonsfil består hovedsakelig av moduler. En modul har et attributt Navn som representerer hva modulen gjør. Verdien av Navn attributt tilsvarer en klasse i plugin-koden som kjøres når plugin kjøres.

La oss lære om de forskjellige modulene i konfigurasjonen ovenfor.

5.3. Moduldetaljer

• Checker: Moduler er strukturert i et tre som har Checker-modulen i roten. Denne modulen definerer egenskapene som arves av alle andre moduler i konfigurasjonen.
• TreeWalker: Denne modulen sjekker de enkelte Java-kildefilene og definerer egenskaper som er gjeldende for å sjekke slike filer.
• Unngå StarImport: Denne modulen setter en standard for ikke å bruke Star-import i Java-koden vår. Det har også en egenskap som ber pluginet om å rapportere alvorlighetsgraden av slike problemer som en advarsel. Når slike brudd blir funnet i koden, vil det altså bli advart mot dem.

For å lese mer om tilpassede konfigurasjoner, følg denne lenken.

6. Rapportanalyse for Spring-Rest Project

I denne delen skal vi belyse en analyse gjort av Checkstyle, ved å bruke den tilpassede konfigurasjonen opprettet i seksjon 5 ovenfor, på fjærprosjektet som er tilgjengelig på GitHub som et eksempel.

6.1. Generering av bruddrapport

Vi har importert konfigurasjonen til Eclipse IDE, og her er bruddrapporten som genereres for prosjektet:

Advarslene som er rapportert her sier at import av jokertegn bør unngås i koden. Vi har to filer som ikke overholder denne standarden. Når vi klikker på advarselen, tar det oss til Java-filen som har brudd.

Her er hvordan HeavyResourceController.java filen viser advarselen som er rapportert:

6.2. Problemløsning

Å bruke Star-import er ikke en god praksis generelt, da det kan skape konflikter når to eller flere pakker inneholder samme klasse.

Tenk på klassen som et eksempel Liste, hvilken er tilgjengelig i pakker java.util og java.awt både. Hvis vi bruker både import av java.util . * og java.awt. * kompilatoren vår klarer ikke å kompilere koden, som Liste er tilgjengelig i begge pakkene.

For å løse problemet nevnt ovenfor organiserer vi importen i begge filene og lagrer dem. Nå når vi kjører pluginet igjen, ser vi ikke bruddene, og koden vår følger nå standardene som er satt i vår tilpassede konfigurasjon.

7. Konklusjon

I denne artikkelen har vi dekket det grunnleggende for å integrere Checkstyle i Java-prosjektet vårt.

Vi har lært at det er et enkelt, men kraftig verktøy som brukes til å sikre at utviklere overholder kodingsstandardene som er satt av organisasjonen.

Eksempelkoden vi brukte for statisk analyse er tilgjengelig på GitHub.