Ce instrumente de analiză a codului utilizați pentru proiectele dvs. Java?

Checkstyle is another one I've used at a previous company... it's mainly for style checking, but it can do some static analysis too. Also, Clover for code coverage, though be aware it is not a free tool.

Noi folosim FindBugs și JDepend integrate cu Ant. Utilizăm JUnit, dar nu folosim niciun instrument de acoperire.

Nu o folosesc integrată în aplicația Rational Application Developer (IDE-ul pe care îl folosesc pentru a dezvolta aplicații J2EE), pentru că îmi place cât de curată pare atunci când executați javac în consola Windows. : P

Caut multe răspunsuri pentru a învăța despre noile instrumente și pentru a consolida aceste cunoștințe într-o singură întrebare / subiect, așa că mă îndoiesc că va fi un adevărat răspuns la această întrebare.

Răspunsul meu la întrebarea mea este că folosim:

• Găsiți bug-uri pentru a căuta erori frecvente rău / codare - rulați de la Maven și, de asemenea, se integrează cu ușurință în Eclipse
• Cobertura pentru rapoartele noastre de acoperire - rulați din maven

Hudson are, de asemenea, un plugin de sarcină-scanner care va afișa un număr de TODO și FIXME, precum și arată unde sunt în fișierele sursă.

Toate sunt integrate cu Maven 1.x în cazul nostru și legate în Hudson, care rulează construirile noastre la check-in, precum și lucruri suplimentare pe timp de noapte și săptămânal. Tendința Hudson descrie testele JUnit, acoperirea, gașcașii, precum și sarcinile deschise. Există, de asemenea, un plugin Hudson care raportează și grafice avertismentele noastre compilate. De asemenea, avem mai multe teste de performanță cu propriile grafice de performanță și de utilizare a memoriei în timp folosind pluginul Hudson plots.

Folosesc analiza statică încorporată în IntelliJ IDEA. Integrare perfectă.

Eu folosesc acoperirea de cod încorporată în Intellij IDEA (bazată pe EMMA). Din nou, integrare perfectă.

Această soluție integrată este fiabilă, puternică și ușor de utilizat în comparație cu combinarea instrumentelor de la diferiți furnizori.

Folosim FindBugs și Checkstyle, precum și Clover pentru acoperirea codului.

Cred că este important să aveți o analiză statică, care să vă susțină dezvoltarea. Din păcate, încă nu este larg răspândită faptul că aceste instrumente sunt importante.

Echipa noastră utilizează PMD și Cobertura, de fapt proiectele noastre sunt proiecte de maven și este foarte simplu să includeți plug-ins pentru analiza codului. Întrebarea reală ar fi pentru un proiect specific pe care trebuie să-l folosiți, opinia mea este că nu puteți utiliza aceleași plugin-uri pentru fiecare proiect.

Pentru instrumentele de analiză statică folosesc adesea CPD, PMD , FindBugs și Checkstyle .

CPD este instrumentul PMD "Copy / Paste Detector". Folosesc PMD puțin timp înainte de a observa link-ul "Găsirea codului duplicat" pagina web PMD .

Aș dori să subliniez că uneori aceste instrumente pot fi extinse dincolo de setul de reguli "out-of-the-box". Și nu doar pentru că sunt sursă deschisă pentru a le putea rescrie. Unele dintre aceste instrumente vin cu aplicații sau "cârlige" care le permit să fie extinse. De exemplu, PMD vine cu instrumentul "designer" care vă permite să creați noi reguli. De asemenea, Checkstyle are controlul DescendantToken care are proprietăți care permit personalizarea substanțială.

Eu integrez aceste instrumente cu un constructor bazat pe Ant . Puteți să urmați linkul pentru a vedea configurația mea comentată.

În plus față de integrarea simplă în construcție, mi se pare util să configurez instrumentele să fie oarecum "integrate" în câteva alte moduri. Anume, generarea de rapoarte și uniformitatea suprimării avertismentelor. Aș dori să adaug aceste aspecte la această discuție (care ar trebui probabil să aibă și eticheta "analiză statică"): cum sunt oamenii configurând aceste instrumente pentru a crea o soluție "unificată"? (Am pus această întrebare separat aici )

În primul rând, pentru rapoartele de avertizare, eu transform de ieșire, astfel încât fiecare avertisment are format simplu:

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

Acest lucru este adesea numit "format Emacs", dar chiar dacă nu utilizați Emacs, este un format rezonabil pentru omogenizarea rapoartelor. De exemplu:

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

Formatele mele de transformare de avertizare sunt efectuate de scriptul meu Ant cu Ant filtru .

A doua "integrare" pe care o fac este pentru suprimarea avertismentelor. În mod prestabilit, fiecare instrument acceptă comentarii sau o adnotare (sau ambele) pe care le puteți plasa în codul dvs. pentru a tăcea un avertisment pe care doriți să îl ignorați. Dar aceste cereri diferite de suprimare a avertismentului nu au un aspect consistent care pare oarecum prostie. Când suprimați un avertisment, reprimați un avertisment, de ce să nu scrieți întotdeauna " SuppressWarning ?"

De exemplu, configurația implicită a PMD suprimă generarea de avertizare pe liniile de cod cu un șir " NOPMD " într-un comentariu. De asemenea, PMD acceptă adnotarea @SuppressWarnings a Java. Confirmați PMD să utilizeze comentariile care conțin SuppressWarning (PMD. "în loc de NOPMD ), astfel încât suprimările PMD să arate la fel. suprimarea stilului:

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

Numai partea " SuppressWarnings (PMD. " este semnificativă pentru un comentariu, dar este compatibilă cu suportul PMD pentru adnotarea @SuppressWarning

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

Similarly, Checkstyle suppresses warning generation between pairs of comments (no annotation support is provided). By default, comments to turn Checkstyle off and on contain the strings CHECKSTYLE:OFF and CHECKSTYLE:ON, respectively. Changing this configuration (with Checkstyle's "SuppressionCommentFilter") to use the strings "BEGIN SuppressWarnings(CheckStyle." and "END SuppressWarnings(CheckStyle." makes the controls look more like PMD:

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

Cu comentariile Checkstyle, violarea specială a verificării ( HiddenField ) este semnificativă, deoarece fiecare cec are propria pereche de comentarii BEGIN / END ".

FindBugs suportă, de asemenea, suprimarea generațiilor de avertizare cu o adnotare @SuppressWarnings , astfel încât nu este necesară o altă configurație pentru a atinge un anumit nivel de uniformitate cu alte instrumente. Din păcate, Findbugs trebuie să suporte o adnotare personalizată @SuppressWarnings , deoarece adnotarea Java @SuppressWarnings încorporată are o politică de păstrare SOURCE care nu este puternică suficient pentru a păstra adnotarea în fișierul de clasă unde FindBugs are nevoie de ea. Calificăm pe deplin calculele de avertizare FindBugs pentru a evita contracararea cu adnotarea @SuppressWarnings a Java:

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

Aceste tehnici fac ca lucrurile să pară în mod rezonabil consecvente între instrumente. Rețineți că dacă fiecare suprimare a avertismentelor conține șirul " SuppressWarnings " este ușor să executați o căutare simplă pentru a găsi toate instanțele pentru toate uneltele de pe o bază de cod întregă.

Folosesc o combinație de Cobertura, Checkstyle, (Ecl) Emma și Findbugs.

EclEmma is an awesome Eclipse plugin that shows the code coverage by coloring the java source in the editor (screenshot) - the coverage is generated by running a JUnit test. This is really useful when you are trying to figure out which lines are covered in a particular class, or if you want to see just which lines are covered by a single test. This is much more user friendly and useful than generating a report and then looking through the report to see which classes have low coverage.

Pluginurile Checkstyle și Findbugs Eclipse sunt, de asemenea, utile, ele generează avertismente în editor, pe măsură ce tastați.

Maven2 are module de raportare care lucrează cu instrumentele de mai sus pentru a genera rapoarte la momentul construirii. Utilizăm acest lucru pentru a obține rapoarte generale despre proiecte, care sunt mai utile atunci când doriți numere agregate. Acestea sunt generate de clădirile CI care rulează folosind Continuum .

Toate cele ce urmează se utilizează și se integrează ușor în ambele module Maven 2.x și Eclipse / RAD 7:

• Testarea - JUnit / TestNG
• Analiza codului - FindBugs, PMD
• Acoperire cu cod - Trifoi

În plus, în construcțiile noastre Maven avem:

• JDepend
• Verificatorul de etichete (TODO, FIXME, etc)

În plus, dacă utilizați Maven 2.x, CodeHaus are o colecție de pluginuri Maven la îndemână în proiectul Mojo .

Notă: Clover are o integrare extraordinară cu serverul Bamboo CI (deoarece sunt ambele produse Atlassian). Există, de asemenea, pluginuri Bamboo pentru FindBugs, PMD și CheckStyle, dar, după cum sa menționat, serverul Hudson CI gratuit are și ele aceste.

Am avut noroc cu Cobertura. Este un instrument de acoperire a codului care poate fi executat prin intermediul script-ului dvs. de furnică ca parte a construirii dvs. normale și poate fi integrat în Hudson.

în proiectul nostru folosim Sonar în fața checkstyle, pmd .... împreună cu CI (Bamboo, Hudson), avem și o istorie frumoasă a calității sursei noastre și ce direcție mergem. Îmi place Sonar, pentru că tu ești un instrument central în CI Stack care te face pentru tine și poți personaliza ușor regulile pentru fiecare proiect.

Structure 101 is good at code analysis and finding the cyclic package dependencies.