Uvod u CheckStyle

1. Pregled

Checkstyle je alat otvorenog koda koji provjerava kôd prema podesivom skupu pravila.

U ovom uputstvu ćemo pogledati kako integrirati Checkstyle u Java projekt putem Mavena i pomoću IDE dodataka.

Dodaci spomenuti u donjim odjeljcima ne ovise jedni o drugima i mogu se pojedinačno integrirati u našu izgradnju ili IDE-ove. Na primjer, dodatak Maven nije potreban u našem pom.xml za pokretanje provjera valjanosti u našem Eclipse IDE-u.

2. Checkstyle Maven dodatak

2.1. Maven konfiguracija

Da bismo projektu dodali Checkstyle, moramo dodati dodatak u odjeljku za izvještavanje a pom.xml:

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

Ovaj dodatak dolazi s dvije unaprijed definirane provjere, provjerom u stilu Sunca i provjerom u Googleovom stilu. Zadana provjera za projekt je sun_checks.xml.

Da bismo koristili našu prilagođenu konfiguraciju, možemo odrediti našu konfiguracijsku datoteku kao što je prikazano u gornjem primjeru. Koristeći ovu konfiguraciju, dodatak će sada čitati našu prilagođenu konfiguraciju umjesto zadane zadane.

Najnoviju verziju dodatka možete pronaći na Maven Central.

2.2. Generiranje izvješća

Sada kada je naš Maven dodatak konfiguriran, možemo generirati izvješće za naš kôd pokretanjem mvn stranica naredba. Nakon završetka izrade, izvještaj je dostupan u cilj / mjesto mapa pod imenom checkstyle.html.

Tri su glavna dijela izvješća Checkstyle:

Datoteke: Ovaj dio izvješća pruža nam sljedeće informacije popis datoteka u kojima su se dogodila kršenja. Također nam pokazuje brojeve prekršaja prema njihovoj ozbiljnosti. Evo kako izgleda odjeljak datoteka u izvješću:

Pravila: Ovaj dio izvještaja daje nam pregled pravila koja su korištena za provjeru kršenja. Prikazuje kategoriju pravila, broj kršenja i težinu tih kršenja. Evo primjera izvješća koji prikazuje odjeljak s pravilima:

Pojedinosti: Konačno, odjeljak s detaljima izvješća pruža nam detalje kršenja koja su se dogodila. Navedeni detalji nalaze se na razini broja retka. Evo primjera odjeljka pojedinosti izvješća:

2.3. Izgradite integraciju

Ako postoji potreba za strogom provjerom stila kodiranja, dodatak možemo konfigurirati na takav način da izrada ne uspije kada se kod ne pridržava standarda.

To radimo dodavanjem cilja izvršenja našoj definiciji dodatka:

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

The configLocation atribut definira na koju konfiguracijsku datoteku se poziva za provjere valjanosti.

U našem slučaju, konfiguracijska datoteka je checkstyle.xml. Cilj ček spomenuto u odjeljku izvršenja traži dodatak da se izvodi u fazi provjere gradnje i prisiljava kvar gradnje kada se dogodi kršenje standarda kodiranja.

Sada, ako pokrenemo mvn čista instalacija naredba, skenirat će datoteke na kršenja, a izrada neće uspjeti ako se pronađu bilo kakva kršenja.

Također možemo pokretati samo ček cilj korištenja dodatka mvn checkstyle: provjeri, bez konfiguriranja cilja izvršenja. Izvođenje ovog koraka rezultirat će i neuspjehom gradnje ako postoje pogreške u provjeri.

3. Dodatak za pomrčinu

3.1. Konfiguracije

Baš kao i s Maven integracijom, Eclipse nam omogućuje upotrebu naše prilagođene konfiguracije.

Da biste uvezli našu konfiguraciju, idite na Prozor -> Postavke -> Checkstyle. Na Globalne konfiguracije provjere odjeljak, kliknite na Novi.

To će otvoriti dijalog koji će nam pružiti opcije za specificiranje naše prilagođene konfiguracijske datoteke.

3.2. Pregledavanje izvješća

Sada kada je naš dodatak konfiguriran, možemo ga koristiti za analizu koda.

Da biste provjerili stil kodiranja za projekt, desnom tipkom miša kliknite projekt u Eclipse Project Explorer i odaberite CheckStyle -> Check code with Checkstyle.

Dodatak će nam dati povratne informacije o našem Java kodu u Eclipseu, uređivaču teksta. Također će generirati izvještaj o kršenju za projekt koji je dostupan kao prikaz u Eclipseu.

Da biste pogledali prijavu kršenja, idite na Prozor -> Prikaži prikaz -> Ostaloi potražite Checkstyle. Opcije za Kršenja i Grafikon kršenja treba prikazati.

Odabirom bilo koje opcije dobit ćemo prikaz kršenja grupiranih prema vrsti. Evo tortnog grafikona kršenja za primjer projekta:

Klik na odjeljak tortnog grafikona dovest će nas do popisa stvarnih kršenja u kodu.

Alternativno, možemo otvoriti Problem pogled na Eclipse IDE i provjerite probleme prijavljene dodatkom.

Evo primjera Prikaz problema Eclipse IDE-a:

Klik na bilo koje upozorenje odvest će nas do koda u kojem se dogodilo kršenje.

4. Dodatak IntelliJ IDEA

4.1. Konfiguracija

Kao i Eclipse, IntelliJ IDEA također nam omogućuje korištenje vlastitih prilagođenih konfiguracija s projektom.

U IDE otvorite Postavke i potražite Checkstyle. Prikazuje se prozor koji ima mogućnost odabira naših čekova. Klikni na + gumb i otvorit će se prozor koji će nam omogućiti da odredimo mjesto datoteke koja će se koristiti.

Sada odabiremo konfiguracijsku XML datoteku i kliknite Dalje. Ovo će otvoriti prethodni prozor i prikazati našu novo dodanu mogućnost prilagođene konfiguracije. Odabiremo novu konfiguraciju i kliknite U redu da bismo je počeli koristiti u našem projektu.

4.2. Pregledavanje izvješća

Sad kad je naš dodatak konfiguriran, upotrijebimo ga za provjeru kršenja. Da biste provjerili krši li određeni projekt, idite na Analizirajte -> Pregledajte kod.

Rezultati inspekcija pružit će nam prikaz kršenja u odjeljku Checkstyle. Evo primjera izvješća:

Klikom na prekršaje doći ćemo do točnih crta u spisu u kojima su se dogodila kršenja.

5. Prilagođena konfiguracija stila provjere

U odjeljku za generiranje izvještaja Maven (odjeljak 2.2) koristili smo prilagođenu konfiguracijsku datoteku za vlastite provjere standardnog kodiranja.

Imamo način za stvaranje vlastite XML datoteke s prilagođenom konfiguracijom ako ne želimo koristiti zapakirane Googleove ili Sun čekove.

Evo prilagođene konfiguracijske datoteke koja se koristi za gore navedene provjere:

5.1. DOCTYPE Definicija

Prvi redak tj. Definicije DOCTYPE važan je dio datoteke i govori odakle treba preuzeti DTD kako bi sustav mogao razumjeti konfiguracije.

Ako ovu definiciju ne uključimo u našu konfiguracijsku datoteku, to neće biti valjana konfiguracijska datoteka.

5.2. Moduli

Datoteka za konfiguraciju sastoji se prvenstveno od modula. Modul ima atribut Ime što predstavlja ono što modul radi. Vrijednost Ime atribut odgovara klasi u kodu dodatka koja se izvršava prilikom pokretanja dodatka.

Naučimo o različitim modulima koji su prisutni u gore navedenom configu.

5.3. Pojedinosti modula

  • Checker: Moduli su strukturirani u stablu koje ima modul Checker u korijenu. Ovaj modul definira svojstva koja nasljeđuju svi ostali moduli konfiguracije.
  • Drvored: Ovaj modul provjerava pojedinačne Java izvorne datoteke i definira svojstva koja su primjenjiva na provjeru takvih datoteka.
  • AvoidStarImport: Ovaj modul postavlja standard za neupotrebu uvoza Star u našem Java kodu. Također ima svojstvo koje traži dodatak da ozbiljnost takvih problema izvještava kao upozorenje. Stoga će se, kad god se takva kršenja nađu u kodu, upozoriti na njih.

Da biste pročitali više o prilagođenim konfiguracijama, slijedite ovu vezu.

6. Analiza izvještaja za projekt Spring-Rest

U ovom ćemo odjeljku rasvijetliti analizu koju je proveo Checkstyle, koristeći prilagođenu konfiguraciju izrađenu u odjeljku 5 gore, na projektu proljetnog odmora dostupan na GitHubu kao primjer.

6.1. Stvaranje izvještaja o kršenju

Uvezli smo konfiguraciju u Eclipse IDE i evo izvješća o kršenju podataka koje se generira za projekt:

Ovdje navedena izvješća kažu da se u kodu treba izbjegavati uvoz zamjenskih znakova. Imamo dvije datoteke koje nisu u skladu s ovim standardom. Kada kliknemo na upozorenje, vodi nas do Java datoteke koja ima kršenje.

Evo kako HeavyResourceController.java datoteka prikazuje prijavljeno upozorenje:

6.2. Rješavanje problema

Korištenje uvoza Star općenito nije dobra praksa jer može stvoriti sukobe kada dva ili više paketa sadrže istu klasu.

Kao primjer uzmite razred Popis, koji je dostupno u paketima java.util i java.awt oba. Ako koristimo oba uvoza java.util . * i java.awt. * naš kompajler neće uspjeti prevesti kod, kao Popis dostupan je u oba paketa.

Da bismo riješili gore spomenuti problem, organiziramo uvoz u obje datoteke i spremamo ih. Sada kada ponovo pokrenemo dodatak, ne vidimo kršenja i naš kod sada slijedi standarde postavljene u našoj prilagođenoj konfiguraciji.

7. Zaključak

U ovom smo članku pokrili osnove integriranja Checkstyle-a u naš Java projekt.

Saznali smo da je to jednostavan, ali moćan alat koji se koristi kako bi se osiguralo da se programeri pridržavaju standarda kodiranja koje je postavila organizacija.

Uzorak koda koji smo koristili za statičku analizu dostupan je na GitHubu.


$config[zx-auto] not found$config[zx-overlay] not found