Praktyczna Java. Checkstyle

Każdy, kto choć raz pra­cow­ał w więk­szym zes­pole zapewne nier­az spotkał się z różny­mi prob­le­ma­mi — inne ustaw­ienia for­ma­towa­nia, spac­je i tab­u­lac­je, inna kon­wenc­ja kodu. Na szczęś­cie jest staty­cz­na anal­iza kodu — dzisi­aj o Checkstyle!

Check­style, jak sama nazwa wskazu­je, służy do kon­trolowa­nia sty­lu. Domyśl­nie sprawdza on wiele ele­men­tów, które mogą się wydawać uciążli­we, ale każde sprawdze­nie moż­na skon­fig­urować indy­wid­u­al­nie, a także napisać własne reguły!

Użycie Checkstyle w projekcie

Aby Twój pro­jekt mógł korzys­tać z Check­style, masz trzy możli­woś­ci możli­woś­ci — uruchami­ać go osob­no, korzys­tać z wty­cz­ki w środowisku (np. Eclipse) lub połączyć z pro­ce­sem budowa­nia (np. Maven­em lub Ant). Pole­camy szczegól­nie połącze­nie dwóch ostat­nich opcji — dzię­ki temu będziesz miała na bieżą­co infor­ma­c­je, że coś co napisałaś nie jest zgodne ze wspól­ny­mi zasada­mi, a jed­nocześnie jeśli przeoczysz taki prob­lem, to pro­jekt się nie zbuduje.

Uruchamianie z linii komend

Jeśli z jakiegoś powodu chcesz tylko sprawdz­ić kod jed­no­ra­zowo, ale nie chcesz włączać check­style w pro­ces budowa­nia pro­jek­tu, możesz uru­chomić go z linii komend. Po pobra­niu pliku JAR i mając przy­go­towaną kon­fig­u­rację, może­my po pros­tu uru­chomić sprawdze­nie za pomocą następu­jącego polecenia:

java -jar checkstyle.jar -c /sun_checks.xml ./MyClass.java

To sprawdzi tylko jed­ną klasę — aby sprawdz­ić np. cały kat­a­log i wszys­tkie pli­ki Java w nim zawarte, może­my sko­rzys­tać z następu­jącego polecenia:

java -jar checkstyle.jar -c /sun_checks.xml ./src

Pełną doku­men­tację, jak uru­chomić check­style w różnych kon­fig­u­rac­jach z linii komend zna­jdziesz w ofic­jal­nym tuto­ri­alu.

Korzystanie z checkstyle w Eclipse

Aby sko­rzys­tać z Check­style w eclipse, możesz sko­rzys­tać z gotowego plug­inu. W tym celu wybierz opcję ‘Eclipse Mar­ket­place’ w menu help, a następ­nie wyszukaj ‘Check­style’ — po chwili pojawi się odpowied­nie opcja.

Jeśli posi­adasz starszą wer­sję, możesz sko­rzys­tać z ‘trady­cyjnego’ sposobu insta­lacji — Z menu Help wybierz opcję ‘Install new soft­ware’, a następ­nie w polu ‘Work with’ wpisz adres: http://eclipse-cs.sf.net/update i zatwierdź enterem. Po chwili poniżej pojawi się opc­ja insta­lacji odpowied­niego pluginu.

Szczegółowy porad­nik krok po kroku zna­jdziesz np. na stron­ie vogella.com lub na stron­ie plug­inu.

Instalacja w IntelliJ IDEA

Oczy­wiś­cie dla Intel­liJ IDEA także ist­nieje gotowy plu­g­in do Check­style — zna­jdziesz go tutaj: https://plugins.jetbrains.com/plugin/1065

Korzystanie z checkstyle w procesie budowania (np. z użyciem Mavena)

W przy­pad­ku Mave­na ist­nieją trzy opc­je korzys­ta­nia z Check­style. Pier­wsza pole­ga na tym, że przy każdym buildzie zostanie wygen­erowany raport ze sprawdza­nia — będą w nim wyp­isane wszys­tkie ‘prob­le­my’, wraz z plika­mi oraz lini­a­mi, w których się dane prob­le­my zna­j­du­ją. Nie będzie to miało jed­nak wpły­wu na powodze­nie lub niepowodze­nie samego budowa­nia pro­jek­tu. Taką kon­fig­u­rację może­my akty­wować doda­jąc poniższą sekcję do pom.xml:

<project>
  ...
   <reporting>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-checkstyle-plugin</artifactId>
          <version>2.17</version>
          <reportSets>
            <reportSet>
              <reports>
                <report>checkstyle</report>
              </reports>
            </reportSet>
          </reportSets>
        </plugin>
      </plugins>
    </reporting>
  ...
</project>

Dru­gi sposób to włącze­nie check­style jako eta­pu budowa­nia pro­jek­tu — jeśli zostaną ‘zauważone’ błędy, to build się nie uda. Aby włączyć taki sposób inte­gracji, możesz użyć poniższej konfiguracji:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-checkstyle-plugin</artifactId>
   <version>2.17</version>
   <executions>
     <execution>
       <id>validate</id>
       <phase>validate</phase>
       <configuration>
         <configLocation>checkstyle.xml</configLocation>
         <encoding>UTF-8</encoding>
         <consoleOutput>true</consoleOutput>
         <failsOnError>true</failsOnError>
         <linkXRef>false</linkXRef>
       </configuration>
       <goals>
         <goal>check</goal>
       </goals>
     </execution>
   </executions>
 </plugin>

Pełną doku­men­tację i inne przykłady zna­jdziesz na stron­ie pro­jek­tu. Zwróć uwagę, że w obu przy­pad­kach musisz podać ścieżkę do pliku xml z kon­fig­u­racją (opis kon­fig­u­racji zna­jdziesz poniżej) — może to być zarówno ścież­ka bezwzględ­na (np. C:/checkstyle.xml), jak i względ­na (czyli np. wzglę­dem kat­a­logu src/main/resources).

Inne narzędzia do budowania projektów

Oczy­wiś­cie jeśli Twój pro­jekt nie korzys­ta z Mave­na, a z innej tech­nologii do budowa­nia, to najpraw­dopodob­niej ist­nieje plu­g­in lub sposób, żeby zin­te­grować go z Check­style — jest to na tyle pop­u­lar­na bib­liote­ka, że z pewnoś­cią zna­jdziesz mate­ri­ały w internecie!

Konfiguracja, co ma być sprawdzane

W check­style wbu­dowane są dwa ‘zestawy’ sprawdzeń — reprezen­tu­ją one ofic­jalne wyty­czne doty­czące sty­lu opub­likowane przez Sun orz te uży­wane w Google, ich opis zna­jdziesz na stron­ie pro­jek­tu, a źródła np w ser­wisie github. Kon­fig­u­rac­je w postaci plików XML zna­jdziesz w kom­ple­cie z samym narzędziem.

Oczy­wiś­cie możli­we jest stworze­nie włas­nej kon­fig­u­racji — wystar­czy odpowied­nio przy­go­tować plik XML. Najczęś­ciej warto zacząć od już gotowego zestawu, i ewen­tu­al­nie mody­fikować go w miarę jak pro­jekt się rozwi­ja, a wraz z nim jego potrze­by czy konwencje.

Tworze­nie pliku kon­fig­u­ra­cyjnego ogranicza się najczęś­ciej do wybra­nia spośród ist­nieją­cych już sprawdzeń tych, które odpowiada­ją uży­wanym przez nas kon­wencjom — listę wszys­t­kich (dostęp­nych domyśl­nie) zna­jdziesz oczy­wiś­cie w doku­men­tacji.

W sieci zna­jdziesz też wiele gotow­ców — wystar­czy wpisać w wyszuki­warkę ‘check­style con­fig­u­ra­tion file’. Jeśli pracu­jesz w więk­szej fir­mie — poszukaj w wewnętrznych mate­ri­ałach, ist­nieje szansa, że ktoś przy­go­tował już zestaw reguł odzwier­cied­la­ją­cy kon­wenc­je firmy :)

Inną opcją na kon­fig­u­rację Check­style jest stworze­nie włas­nych sprawdzeń i sposobów, w jaki kod będzie anal­i­zowany. Sprawdzenia takie sprowadza­ją się do napisa­nia klasy w Javie imple­men­tu­jącej odpowied­ni inter­fe­js, ale koniecz­na jest pod­sta­wowa wiedza na tem­at przetwarza­nia i kom­pi­lacji kodu — w szczegól­noś­ci rozu­mie­nie, czym jest AST (abstract syn­tax tree) oraz jak z niego korzys­tać. Przys­tep­ny tuto­r­i­al możesz znaleźć np. w doku­men­tacji Check­style. Możesz także zerknąć na pro­jekt sevn­tu-check­style, gdzie zna­jdziesz dodatkowe sprawdzenia stwor­zone przez insty­tut tech­niczny w Sewastopolu.

Podsumowanie

O ile najwięk­szą wartość moż­na ‘zauważyć’ w pro­jek­tach, nad który­mi pracu­je wiele osób, to także jeśli sama piszesz pro­jekt Check­style jest narzędziem wartym rozważe­nia — może pomóc Ci pisać czytel­niejszy kod oraz zwró­cić uwagę na ele­men­ty, o których wcześniej nie myślałaś. Jest to jed­no z 2 narzędzi do staty­cznej anal­izy kodu, które są właś­ci­wie stan­dar­d­em pra­cy z pro­jek­ta­mi w Javie — drugie także omówimy na łamach blo­ga już wkrótce :)

Oczy­wiś­cie podob­ne narzędzia ist­nieją także dla innych języków, np Ruby (rubo­cop), Python (różne), C# (Style­Cop, FxCop)