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

Question

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

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

Jestem zainteresowany wszelkimi rodzajami

narzędzia do analizy statycznej kodu (FindBugs, PMD i inne)
code coverage tools (Cobertura, Emma i inne)
wszelkie inne narzędzia oparte na oprzyrządowaniu
cokolwiek innego, jeśli coś mi umyka

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

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 są również warte uwagi.

108

java static-analysis code-coverage

Author: Bill the Lizard, 2008-08-07

Source

12 answers

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

EclEmma jest awesome Eclipse plugin, który pokazuje pokrycie kodu poprzez kolorowanie źródła Javy w edytorze ( screenshot ) - pokrycie jest generowane przez uruchomienie testu JUnit. Jest to bardzo przydatne, gdy próbujesz dowiedzieć się, które linie są objęte daną 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ą niski zasięg.

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

Maven2 posiada wtyczki do raportów, które współpracują z powyższymi narzędziami do generowania raportów w czasie kompilacji. Używamy tego, aby uzyskać ogólne raporty projektu, które są bardziej przydatne, gdy chcesz zagregowane liczby. Są one generowane przez nasze Ci buildy, które działają przy użyciu Continuum .

16

Author: Ken Liu,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-10-29 18:55:44

Wszystkie poniższe elementy wykorzystujemy i integrujemy easiy w naszym Maven 2.x buduje i Eclipse / RAD 7:

Testowanie-JUnit / TestNG
Analiza kodu-FindBugs, PMD
pokrycie kodu-koniczyna

DODATKOWO w naszych kompilacjach Mavena mamy:

JDepend
Tag checker (TODO, FIXME, itp.)

Ponadto, jeśli używasz Mavena 2.x, CodeHaus posiada zbiór przydatnych wtyczek Mavena w swoim Mojo project .

Uwaga: Clover ma gotową integrację z serwerem CI Bamboo (ponieważ oba są produktami Atlassian). Istnieją również bambusowe wtyczki do FindBugs, PMD i CheckStyle, ale, jak wspomniano, darmowy serwer Ci Hudson też je ma.

11

Author: Brian Laframboise,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-16 18:48:43

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

Używam kodu wbudowanego w Intellij IDEA (opartego na Emmie). Znowu doskonała integracja.

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

8

Author: Steve McLeod,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 14:40:53

Checkstyle to kolejny, którego używałem w poprzedniej firmie... służy głównie do sprawdzania stylu, ale może również wykonać analizę statyczną. Również, Clover dla pokrycia kodu, choć należy pamiętać, że nie jest to darmowe narzędzie.

4

Author: Mike Stone,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-07 07:18:26

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 wciąż nie jest szeroko rozpowszechnione, że te narzędzia są ważne.

3

Author: dlinsin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-07 07:21:49

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

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

1

Author: ggasp,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-07 00:20:41

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

1

Author: Randyaa,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 04:31:07

Nasz zespół korzysta z PMD i Cobertury, w rzeczywistości nasze projekty są projektami maven i bardzo proste jest dołączanie wtyczek do analizy kodu. Prawdziwe pytanie byłoby dla konkretnego projektu, którą analizę trzeba użyć, moim zdaniem jest to, że nie można użyć tych samych wtyczek dla każdego projektu.

1

Author: vaske,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-09-17 14:46:25

W naszym projekcie używamy sonaru przed checkstyle, pmd.... razem z CI (Bamboo, Hudson) otrzymujemy również ładną historię jakości naszych źródeł i tego, co kierujemy. Lubię 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.

1

Author: OneCent,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-08-29 09:56:05

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

1

Author: Jeffrey Lee,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-17 06:59:00

Szukam wielu odpowiedzi, aby dowiedzieć się o nowych narzędziach i utrwalić tę wiedzę w jednym pytaniu/wątku, więc wątpię, że będzie 1 prawdziwa odpowiedź na to pytanie.

Moja odpowiedź na własne pytanie brzmi:

Findbugs do wyszukiwania typowych błędów bad / coding-Uruchom z Mavena, a także łatwo integruje się z Eclipse
Cobertura dla naszych raportów-Uruchom z maven

Hudson posiada również wtyczkę task-scanner, która wyświetli liczbę Twoje TODO i FIXMEs, a także pokaż, gdzie są w plikach źródłowych.

Wszystkie są zintegrowane z Maven 1.x w naszym przypadku i związane z Hudson, który prowadzi nasze buildy na odprawy, jak również dodatkowe rzeczy nocnych i tygodniowych. Hudson trend wykresy naszych testów JUnit, coverage, findbugs, a także otwartych zadań. Istnieje również wtyczka Hudson, która raportuje i wykresuje nasze ostrzeżenia kompilacji. Mamy również kilka testów wydajności z własnymi wykresami wydajności i wykorzystania pamięci w czasie za pomocą Hudson plugin również.

0

Author: Joshua McKinnon,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2008-08-08 14:53:12

score 66 · Accepted Answer

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

CPD jest narzędziem PMD "Copy / Paste Detector". Przez jakiś czas używałem PMD, zanim zauważyłem link " znajdowanie zduplikowanego kodu " na stronie PMD.

Chciałbym zauważyć, że te narzędzia mogą być czasami rozszerzone poza ich "out-of-the-box" zestaw zasad. I nie tylko dlatego, że są open source tak że 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 jest dostarczany z narzędziem "designer" , które umożliwia tworzenie nowych reguł. Ponadto, Checkstyle ma DescendantToken sprawdzić, który ma właściwości, które pozwalają na znaczne dostosowanie.

[[25]}integruję te narzędzia z Ant-based build . Możesz kliknąć w link, aby zobaczyć moje komentarze konfiguracja.

Oprócz prostej integracji z kompilacją, pomocne jest skonfigurowanie narzędzi w sposób nieco "zintegrowany" na kilka innych sposobów. Mianowicie, generowanie raportów i jednorodność tłumienia ostrzegania. Chciałbym dodać te aspekty do tej dyskusji (która prawdopodobnie powinna mieć również tag "analiza statyczna"): jak ludzie konfigurują te narzędzia, aby stworzyć "zunifikowane" rozwiązanie? (Zadałem to pytanie osobno tutaj )

Najpierw, dla raportów ostrzegawczych, przekształcam Wyjście 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 homogenizacji raportów. Na przykład:

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

Moje przekształcenia formatu ostrzeżenia są wykonywane przez mój skrypt Ant z ant filterchains .

Druga "integracja", którą do służy do tłumienia ostrzeżeń. Domyślnie każde narzędzie obsługuje komentarze lub adnotację (lub oba), które można umieścić w kodzie, aby wyciszyć Ostrzeżenie, które chcesz zignorować. Ale te różne prośby o tłumienie ostrzeżeń nie mają spójnego wyglądu, który wydaje się nieco głupi. 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 napis "NOPMD " w komentarzu. Ponadto PMD obsługuje adnotację @SuppressWarnings Javy. Konfiguruję PMD tak, aby używał komentarzy zawierających "SuppressWarning(PMD. " zamiast NOPMD tak, aby tłumiki PMD wyglądały podobnie. Wypełniam konkretną regułę, która jest naruszana przy użyciu stylu komentarza:

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

Tylko część" SuppressWarnings(PMD. " jest znacząca dla komentarza, ale jest zgodna ze wsparciem PMD dla adnotacji @SuppressWarning, która rozpoznaje pojedyncze naruszenia reguł przez nazwa:

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

Podobnie, Checkstyle blokuje generowanie ostrzeżeń między parami komentarzy(nie ma obsługi adnotacji). Domyślnie komentarze do wyłączania i włączania Checkstyle zawierają odpowiednio ciągi znaków CHECKSTYLE:OFF i CHECKSTYLE:ON. Zmiana tej konfiguracji (za pomocą Checkstyle ' a "SuppressionCommentFilter") na ciągi "BEGIN SuppressWarnings(CheckStyle. " i "END SuppressWarnings(CheckStyle. " sprawia, że kontrolki wyglądają bardziej jak PMD:

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

Z komentarzami Checkstyle, konkretna Kontrola naruszenie (HiddenField) jest znaczące, ponieważ każdy czek ma własną parę komentarzy " BEGIN/END".

FindBugs obsługuje również tłumienie generowania ostrzeżeń za pomocą adnotacji @SuppressWarnings, więc nie jest wymagana dalsza Konfiguracja, aby osiągnąć pewien poziom jednolitości z innymi narzędziami. Niestety, Findbugs musi obsługiwać niestandardową adnotację @SuppressWarnings, ponieważ wbudowana adnotacja Java @SuppressWarnings ma politykę przechowywania SOURCE, która nie jest wystarczająco silna, aby zachować adnotację w plik klasy, w którym FindBugs go potrzebuje. W pełni kwalifikuję Ostrzeżenia FindBugs, aby uniknąć zderzenia z adnotacją @SuppressWarnings Javy:

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

Te techniki sprawiają, że rzeczy wyglądają dość spójnie we wszystkich narzędziach. Zauważ, że każde Ostrzeżenie zawiera ciąg znaków "SuppressWarnings " ułatwia uruchamianie prostego wyszukiwania, aby znaleźć wszystkie instancje wszystkich narzędzi w całej bazie kodu.