Jakich narzędzi do analizy kodu używasz w projektach Java? [Zamknięte]

Jakich narzędzi do analizy kodu używasz w projektach Java?

Interesują mnie wszelkiego rodzaju

• narzędzia do statycznej analizy kodu (FindBugs, PMD i inne)
• narzędzia pokrycia kodu (Cobertura, Emma i inne)
• wszelkie inne narzędzia oparte na oprzyrządowaniu
• cokolwiek innego, jeśli czegoś mi brakuje

Jeśli ma to zastosowanie, określ również, jakich narzędzi do kompilacji używasz i jak dobrze te narzędzia integrują się zarówno z Twoimi IDE, jak i narzędziami do kompilacji.

Jeśli narzędzie jest dostępne tylko w określony sposób (jako wtyczka IDE lub, powiedzmy, wtyczka narzędzia do budowania), informacje te również są warte odnotowania.

W przypadku narzędzi do analizy statycznej często używam CPD, PMD , FindBugs i Checkstyle .

CPD to narzędzie PMD „Copy / Paste Detector”. Używałem PMD przez jakiś czas, zanim zauważyłem łącze „Finding Duplicated Code” na stronie internetowej PMD .

Chciałbym zaznaczyć, że czasami narzędzia te mogą wykraczać poza ich „gotowy do użycia” zestaw reguł. I to nie tylko dlatego, że są open source, więc możesz je przepisać. Niektóre z tych narzędzi są dostarczane z aplikacjami lub „haczykami”, które umożliwiają ich rozszerzenie. Na przykład PMD zawiera narzędzie „projektant”, które umożliwia tworzenie nowych reguł. Ponadto Checkstyle ma kontrolę DescendantToken, która ma właściwości, które umożliwiają znaczne dostosowanie.

Integruję te narzędzia z kompilacją opartą na Ant . Możesz kliknąć link, aby zobaczyć moją skomentowaną konfigurację.

Oprócz prostej integracji z kompilacją, uważam, że pomocne jest skonfigurowanie narzędzi tak, aby były nieco „zintegrowane” na kilka innych sposobów. Mianowicie generowanie raportów i jednorodność tłumienia ostrzeżeń. Chciałbym dodać te aspekty do tej dyskusji (która prawdopodobnie powinna mieć również tag „static-analysis”): jak ludzie konfigurują te narzędzia, aby stworzyć „ujednolicone” rozwiązanie? (Zadałem to pytanie osobno tutaj )

Po pierwsze, w przypadku raportów ostrzegawczych przekształcam dane wyjściowe, tak aby każde ostrzeżenie miało prosty format:

/absolute-path/filename:line-number:column-number: warning(tool-name): message

Jest to często nazywane „formatem Emacsa”, ale nawet jeśli nie używasz Emacsa, jest to rozsądny format do ujednolicania raportów. Na przykład:

/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.

Moje transformacje formatu ostrzegawczego są wykonywane przez mój skrypt Ant z łańcuchami filtrów Ant .

Druga „integracja”, którą robię, to tłumienie ostrzeżeń. Domyślnie każde narzędzie obsługuje komentarze lub adnotacje (lub obie), które można umieścić w kodzie, aby wyciszyć ostrzeżenie, które chcesz zignorować. Ale te różne prośby o stłumienie ostrzeżeń nie mają spójnego wyglądu, co wydaje się nieco głupie. Kiedy tłumisz ostrzeżenie, tłumisz ostrzeżenie, więc dlaczego nie zawsze pisać „ SuppressWarning?”

Na przykład, domyślna konfiguracja PMD blokuje generowanie ostrzeżeń w wierszach kodu z ciągiem znaków „ NOPMD” w komentarzu. PMD obsługuje również @SuppressWarningsadnotacje w języku Java . Skonfigurowałem PMD tak, aby używał komentarzy zawierających „ SuppressWarning(PMD.” zamiast NOPMDtak, aby blokady PMD wyglądały podobnie. Wypełniam konkretną regułę, która jest naruszana podczas korzystania z pomijania stylu komentarzy:

// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained

Tylko część „ SuppressWarnings(PMD.” ma znaczenie dla komentarza, ale jest zgodna z obsługą przez PMD @SuppressWarningadnotacji, która rozpoznaje poszczególne naruszenia reguł po nazwie:

@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended

Podobnie, Checkstyle wyłącza generowanie ostrzeżeń między parami komentarzy (brak obsługi adnotacji). Domyślnie komentarze wyłączające i włączające Checkstyle zawierają odpowiednio łańcuchy CHECKSTYLE:OFFi CHECKSTYLE:ON. Zmiana tej konfiguracji (za pomocą funkcji „SuppressionCommentFilter” firmy Checkstyle) w celu użycia ciągów „ BEGIN SuppressWarnings(CheckStyle.” i „ END SuppressWarnings(CheckStyle.” powoduje, że kontrolki wyglądają bardziej jak PMD:

// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)

W przypadku komentarzy typu Checkstyle, szczególne naruszenie kontroli ( HiddenField) jest istotne, ponieważ każdy " BEGIN/END" test ma swoją własną parę komentarzy.

FindBugs obsługuje również pomijanie generowania ostrzeżeń z @SuppressWarningsadnotacją, więc nie jest wymagana dalsza konfiguracja, aby osiągnąć pewien poziom ujednolicenia z innymi narzędziami. Niestety, Findbugs musi obsługiwać niestandardową @SuppressWarningsadnotację, ponieważ wbudowana @SuppressWarningsadnotacja Java ma SOURCEpolitykę przechowywania, która nie jest wystarczająco silna, aby zachować adnotację w pliku klasy, w którym FindBugs tego potrzebuje. W pełni kwalifikuję blokady ostrzeżeń FindBugs, aby uniknąć kolizji z @SuppressWarningsadnotacją Java :

@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")

Te techniki sprawiają, że rzeczy wyglądają na dość spójne we wszystkich narzędziach. Należy zauważyć, że umieszczenie każdego pomijania ostrzeżenia w postaci ciągu „ SuppressWarnings” ułatwia przeprowadzenie prostego wyszukiwania w celu znalezienia wszystkich wystąpień wszystkich narzędzi w całej bazie kodu.

Używam kombinacji Cobertury, Checkstyle, (Ecl) Emma i Findbugs.

EclEmma to niesamowita wtyczka Eclipse, która pokazuje pokrycie kodu poprzez kolorowanie źródła Java w edytorze ( zrzut ekranu ) - pokrycie jest generowane przez uruchomienie testu JUnit. Jest to naprawdę przydatne, gdy próbujesz dowiedzieć się, które wiersze są objęte określoną klasą lub jeśli chcesz zobaczyć, które linie są objęte pojedynczym testem. Jest to znacznie bardziej przyjazne dla użytkownika i przydatne niż generowanie raportu, a następnie przeglądanie raportu, aby zobaczyć, które klasy mają niskie pokrycie.

Przydatne są również wtyczki Checkstyle i Findbugs Eclipse, które generują ostrzeżenia w edytorze podczas pisania.

Maven2 ma wtyczki do raportów, które współpracują z powyższymi narzędziami w celu generowania raportów w czasie kompilacji. Używamy tego do uzyskiwania ogólnych raportów z projektów, które są bardziej przydatne, gdy chcesz uzyskać dane zbiorcze. Są one generowane przez nasze kompilacje CI, które działają przy użyciu Continuum .

Wszystkie poniższe elementy, których używamy i integrujemy z łatwością zarówno w naszych kompilacjach Maven 2.x, jak i Eclipse / RAD 7:

• Testowanie - JUnit / TestNG
• Analiza kodu - FindBugs, PMD
• Pokrycie kodu - Clover

Ponadto w naszych kompilacjach Mavena mamy:

• JDepend
• Narzędzie do sprawdzania tagów (TODO, FIXME itp.)

Ponadto, jeśli używasz Maven 2.x, CodeHaus ma kolekcję przydatnych wtyczek Maven w swoim projekcie Mojo .

Uwaga: Clover ma integrację od razu po wyjęciu z pudełka z serwerem Bamboo CI (ponieważ oba są produktami Atlassian). Istnieją również wtyczki Bamboo dla FindBugs, PMD i CheckStyle, ale, jak wspomniano, bezpłatny serwer Hudson CI również je ma.

Używam analizy statycznej wbudowanej w IntelliJ IDEA. Doskonała integracja.

Używam pokrycia kodu wbudowanego w Intellij IDEA (na podstawie EMMA). Ponownie, doskonała integracja.

To zintegrowane rozwiązanie jest niezawodne, wydajne i łatwe w użyciu w porównaniu z narzędziami różnych dostawców.

Checkstyle to kolejna metoda, której używałem w poprzedniej firmie ... służy głównie do sprawdzania stylu, ale może też wykonywać statyczną analizę. Ponadto Clover do pokrycia kodu, chociaż należy pamiętać, że nie jest to darmowe narzędzie.

Używamy FindBugs i Checkstyle, a także Clover do pokrycia kodu.

Myślę, że ważne jest, aby mieć jakąś statyczną analizę, wspierającą Twój rozwój. Niestety nadal nie jest szeroko rozpowszechnione, że te narzędzia są ważne.

Używamy FindBugs i JDepend zintegrowanych z Ant. Używamy JUnit, ale nie używamy żadnego narzędzia pokrycia.

Nie używam go zintegrowanego z Rational Application Developer (IDE, którego używam do tworzenia aplikacji J2EE), ponieważ podoba mi się, jak schludnie wygląda po uruchomieniu javaca w konsoli Windows. : P

Miałem szczęście z Coberturą. Jest to narzędzie do pokrycia kodu, które można uruchomić za pomocą skryptu Ant jako część normalnej kompilacji i zintegrować z Hudson.

Nasz zespół korzysta z PMD i Cobertury, w rzeczywistości nasze projekty są projektami maven i bardzo łatwo jest dołączyć wtyczki do analizy kodu. Prawdziwe pytanie dotyczyłoby konkretnego projektu, z którego analizy należy skorzystać, moim zdaniem nie można użyć tych samych wtyczek dla każdego projektu.

w naszym projekcie używamy Sonara przed checkstyle, pmd .... razem z CI (Bamboo, Hudson) otrzymujemy również fajną historię jakości naszego źródła i tego, na co się kierujemy. Podoba mi się Sonar, ponieważ jesteś jednym centralnym narzędziem w stosie CI, które robi to za Ciebie, i możesz łatwo dostosować zasady dla każdego projektu.

Struktura 101 jest dobra w analizie kodu i znajdowaniu cyklicznych zależności pakietów.

Szukam wielu odpowiedzi, aby poznać nowe narzędzia i skonsolidować tę wiedzę w jednym pytaniu / wątku, więc wątpię, czy będzie 1 prawdziwa odpowiedź na to pytanie.

Moja odpowiedź na moje własne pytanie jest taka, że ​​używamy:

• Znajdź błędy, aby wyszukać typowe błędy, złe / kodowane - uruchamiane z mavena, a także łatwo integrują się z Eclipse
• Cobertura dla naszych raportów o zasięgu - prowadzona przez maven

Hudson ma również wtyczkę do skanowania zadań, która wyświetla liczbę zadań do wykonania i FIXME, a także pokazuje, gdzie się znajdują w plikach źródłowych.

Wszystkie są zintegrowane z Maven 1.x w naszym przypadku i powiązane z Hudsonem, który uruchamia nasze kompilacje podczas odprawy, a także dodatkowe rzeczy co noc i co tydzień. Hudson przedstawia wykresy naszych testów JUnit, pokrycia, znajdowania błędów, a także otwartych zadań. Istnieje również wtyczka Hudson, która raportuje i wyświetla nasze ostrzeżenia dotyczące kompilacji. Mamy również kilka testów wydajności z własnymi wykresami wydajności i wykorzystania pamięci w czasie, używając również wtyczki Hudson plots.