Statyczna analiza kodu cz 3 – PHP Mess Detector cz 1

PHP Mess Detector jest kolejnym narzędziem po PHP_CodeSniffer i kilku innych wcześniej opisanych w tym i w tym poście narzędzi służących do statycznej analizy kodu jakie opiszę. Jeśli z jakiegoś powodu nie przeczytałeś tych wpisów to bardzo zachęcam do zapoznania się z nimi.

A teraz ogólnie o PHPMD

PHPMD (bo tak w skrócie nazwa się to narzędzie) jest to „odprysk” powstały w wyniku tworzenia narzędzia zwanego PHPDepend. Podobnie jak PHP_CodeSniffer najlepiej sprawdza się gdy chcemy przekonać się które fragmenty naszego kodu potencjalnie mogą zawierać błędy, nieużywane parametry lub wskaże fragmenty, które są zbyt skomplikowane.

A teraz o instalacji PHPMD

Sposoby instalacji są raczej standardowe. Po pierwsze można pobrać plik phar za pomocą następującego polecenia:

lub dodać zależność do pliku composer.json:

potem wpisujemy:

i po bólu 😉

A teraz o podstawowych poleceniach w CLI

Po zainstalowaniu PHPMD (ja używam wersji zainstalowanej poprzez composera) możemy przystąpić do analiz naszego projektu. Aby to zrobić należy w CLI wpisać polecenie wg następującego wzorca:

O ile co wpisać w pierwszym parametrze jest raczej jasne to kłopot może być z drugim i trzecim. Otóż PHPMD może nam wyświetlić wynik analizy w trzech różnych formatach: xml, text i html. I właśnie jedną z tych trzech jakie wypisałem przed chwilą wpisuje się jako drugi parametr. Poniżej wynik analizy tego samego kodu w tych trzech różnych formatach:

PHP MD - wynik w XML

PHP MD - wynik w txt

PHP MD - wynik w HTML

Trzeci parametr to nazwa grupy reguł pod kątem, których będzie analizowany nasz kod. Grupa, którą wybrałem w przykładzie powyżej to cleancode. Ta grupa odpowiada za weryfikację m. in. czy kod spełnia zasady SOLID. Oprócz tej grupy isestnieją jeszcze grupy: codesize (odpowiadający za sprawdzanie np complexity), controversial (ta grupa sprawdza czy w kodzie nie korzystamy ze zmiennych superglobalnych lub czy nazewnictwo jest zgodne z konwencją CamelCase), design (ta grupa sprawdza czy w kodzie nie użyliśmy np eval lub goto), naming (ta grupa sprowadza np czy nazwy metod odwzorowują to co w nich się dzieje ), unusedcode (sprawdza czy w kontrolowanym kodzie nie ma jakiś nieużywanych fragmentów).

W ramach jednego polecenia można sprawdzać kod pod kątem kilku grup jednocześnie podając ich nazwy po przecinku jak w przykładzie poniżej:

Można także nazwy grup mieszać z plikami XML zawierający naszą własną grupę reguł. O tym jednak w następnym poście.

A teraz o dodatkowych flagach w CLI

Do dyspozycji mamy 6 flag. Chociaż tak właściwie to 5 ale o tym za chwilkę.

Pierwsza z nich to –minimumpriority. Ustawienie wartości dla tej flagi oznacza, że tylko reguły o ustawionym priorytecie lub wyższym wywołują ostrzeżenia. Przykładowo taki kod php vendor/bin/phpmd ./../code/test/ text naming,unusedcode,design --minimumpriority 3 sprawi że wyświetlą się tylko powiadomienia o priorytecie 3 lub wyższym. Pytanie jednak skąd wiadomo jakie priorytety mają poszczególne reguły? Tą informację można znaleźć w pliku xml opisującym daną grupę reguł. Pliki te znajdują się w katalogu vendor/phpmd/phpmd/src/main/resources/rulesetsW tym pliku każda z reguł opisana jest kilkoma znacznikami a jednym z nich jest właśnie priority.

Druga z nich to –reportfile. Jak nie trudno się domyśleć pozwala na zapisanie wyniku analizy w postaci pliku, którego nazwę podajemy jako argument. I tak gdy wpiszemy w terminal taki kod php vendor/bin/phpmd ./../code/test/ xml naming,unusedcode,design --reportfile phpmd.xmlspowoduje to utworzenie pliku phpmd.xml zawierającego listę problemów jakie PHPMD wykrył w naszym kodzie w postaci pliku XML.

Następna flaga to –suffixes. Tej fladze należy podać oddzielone przecinkami rozszerzenia plików, które mają być poddane analizie. Przykładowo w przypadku takiego kodu php vendor/bin/phpmd ./../code/test/ xml naming,unusedcode,design --suffixes phtmlPHPMD przeanalizuje tylko i wyłącznie kod w plikach o rozszerzeniu phtml.

Czwarta z kolei flaga to —exclude i jak łatwo się domyślić służy do określenia który plik lub katalog w projekcie ma być wykluczony z analizy. Istnieje możliwość podania kilku ścieżek oddzielonych przecinkami.

Przedostatnią dostępną flagą jest –strict. Jeśli ją ustawimy to dostaniem informacje o błędach w kodzie nawet jeśli te fragmenty są opatrzone adnotacją @SuppressWarnings.

Ostatnia flaga to –ignore-violations-on-exita. Domyślnie PHPMD zwraca 1 w przypadku pojawienia się wyjątku i 2 w przypadku wykrycia błędów. Ustawienie tej flagi powoduje, że PHPMD zwraca 0 nawet w przypadku wykrycia w analizowanym kodzie jakiś podatności. Jest tylko jeden problem z tą flagą – ona nie działa. Tak przynajmniej jest w wersji 2.6 którą Wam opisuję. Błąd został już zgłoszony na Githubie i jest nadzieja, że wersja 2.6.1 będzie już go pozbawiona.

A teraz o adnotacjach dla PHPMD

PHPMD daje możliwość konfiguracji swojego zachowania – poprzez adnotacje. Przykładowo – jeśli chcemy aby PHPMD ignorował daną funkcję w adnotacji dla niej należy zapisać coś takiego:

W podobny sposób można ignorować konkretne reguły:

W taki sposób jak powyżej można także wyłączyć kilka reguł dla danego fragmentu kodu wypisując jeden „SuppressWarnings” pod drugim.

Można także wyłączyć ostrzeżenia dla całej grupy reguł w następujący sposób:

Odnośnie wyciszania ostrzeżeń dla całej grupy to nie działa ono dla grupy design. Błąd ten zgłosiłem na GitHubie (tutaj) ale w momencie pisania tego postu nic ciekawego w temacie się nie wydarzyło.

A teraz podsumowanie

I to tyle w pierwszej części postu poświęconego PHPMD. Informacje jakie zawarłem w tym poście w zupełności wystarczą aby komfortowo korzystać z PHPMD. Gdyby jednak ten wpis nie zaspokoił Waszej ciekawości to już niedługo pojawi się kolejny post na temat PHPMD. W nim skoncentruję się na opisaniu procesu tworzeniem własnych reguł i zestawów reguł. Zachęcam do komentowania i do przeczytania już wkrótce!

Posty które mogą Cię zainteresować:

Dodaj komentarz

Your email address will not be published. Please enter your name, email and a comment.