DISABILITARE ADBLOCK

ADBlock sta bloccando alcuni contenuti del sito

ADBlock errore
risultati trovati: 

DOMANDA

Quali strumenti di analisi del codice usi nei tuoi progetti Java?

Sono interessato a tutti i tipi

  • strumenti di analisi del codice statico (FindBugs, PMD e altri)
  • strumenti di copertura del codice (Cobertura, Emma e altri)
  • qualsiasi altro strumento basato sulla strumentazione
  • qualsiasi altra cosa, se mi manca qualcosa

Se applicabile, indica anche quali strumenti di compilazione usi e in che modo questi strumenti si integrano sia con i tuoi IDE che con gli strumenti di costruzione.

Se uno strumento è disponibile solo in un modo specifico (come un plug-in IDE o, diciamo, un plug-in dello strumento di compilazione), anche le informazioni sono degne di nota.

SOLUZIONE

Per gli strumenti di analisi statica utilizzo spesso CPD, PMD , Trova bug e Checkstyle .

CPD è il PMD "Copia / incolla rivelatore" strumento. Stavo usando PMD da un po 'di tempo prima di notare il " Trovare il codice duplicato " link nella pagina web PMD .

Vorrei sottolineare che questi strumenti a volte possono essere estesi oltre il loro "out-of-the-box" insieme di regole. E non solo perché sono open source in modo da poterli riscrivere. Alcuni di questi strumenti vengono forniti con applicazioni o "ganci" che consente di estenderli. Ad esempio, PMD viene fornito con il " designer " strumento che ti consente di creare nuove regole. Inoltre, Checkstyle ha il DescendantToken che ha proprietà che consentono una personalizzazione sostanziale.

Ho integrato questi strumenti con una build basata su formiche . Puoi seguire il link per vedere la mia configurazione commentata.

Oltre alla semplice integrazione nella build, trovo utile configurare gli strumenti per essere un po '"integrati". in un paio di altri modi. Vale a dire, generare generazione e avvertire l'uniformità della soppressione. Vorrei aggiungere questi aspetti a questa discussione (che probabilmente dovrebbe avere anche il tag "analisi statica"): come stanno configurando questi strumenti per creare un "unificato"? soluzione? (Ho posto questa domanda separatamente qui )

Per prima cosa, per i report di avviso, trasformo l'output in modo che ogni avviso abbia il formato semplice:

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

Questo è spesso chiamato il formato " Emacs, " ma anche se non stai usando Emacs, è un formato ragionevole per omogeneizzare i rapporti. Ad esempio:

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

Le mie trasformazioni del formato di avviso vengono eseguite dal mio script Ant con Ant filterchains .

La seconda "integrazione" quello che faccio è per avvertire la soppressione. Per impostazione predefinita, ogni strumento supporta commenti o un'annotazione (o entrambi) che è possibile inserire nel codice per silenziare un avviso che si desidera ignorare. Ma queste varie richieste di soppressione degli avvisi non hanno un aspetto coerente che sembra alquanto sciocco. Quando stai sopprimendo un avviso, stai sopprimendo un avviso, quindi perché non scrivere sempre " SuppressWarning ? & Quot;

Ad esempio, la configurazione predefinita di PMD sopprime la generazione di avvertenze su righe di codice con la stringa " NOPMD " in un commento. Inoltre, PMD supporta l'annotazione @SuppressWarnings di Java. Configuro PMD per utilizzare i commenti contenenti " SuppressWarning (PMD. " invece di NOPMD in modo che le soppressioni di PMD siano simili. Compilare la particolare regola che viene violata quando si utilizza la soppressione dello stile di commento:

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

Solo la parte " SuppressWarnings (PMD. ") è significativa per un commento, ma è coerente con il supporto di PMD per @SuppressWarning annotazione che riconosce le singole violazioni delle regole per nome:

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

Allo stesso modo, Checkstyle sopprime la generazione di avvisi tra coppie di commenti (non viene fornito alcun supporto di annotazione). Per impostazione predefinita, i commenti per attivare e disattivare Checkstyle contengono rispettivamente le stringhe CHECKSTYLE: OFF e CHECKSTYLE: ON . Modifica questa configurazione (con Checkstyle's SuppressionCommentFilter ") per utilizzare le stringhe " BEGIN & nbsp; SuppressWarnings (CheckStyle. " e " END & nbsp; SuppressWarnings (CheckStyle. " rende i controlli più simili a PMD:

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

Con i commenti Checkstyle, la particolare violazione del controllo ( HiddenField ) è significativa perché ogni controllo ha il proprio " BEGIN / END " coppia di commenti.

FindBugs supporta anche la soppressione della generazione di avvisi con un'annotazione @SuppressWarnings , quindi non è necessaria alcuna ulteriore configurazione per raggiungere un certo livello di uniformità con altri strumenti. Sfortunatamente, Findbugs deve supportare un'annotazione personalizzata @SuppressWarnings perché l'annotazione Java @SuppressWarnings integrata ha una politica di conservazione SOURCE che non è forte abbastanza per conservare l'annotazione nel file di classe in cui FindBugs ne ha bisogno. Sono pienamente qualificato per sopprimere gli avvisi FindBugs per evitare di scontrarmi con l'annotazione Java @SuppressWarnings :

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

Queste tecniche rendono le cose ragionevolmente coerenti tra gli strumenti. Tieni presente che ogni soppressione degli avvisi contiene la stringa " SuppressWarnings " semplifica l'esecuzione di una semplice ricerca per trovare tutte le istanze di tutti gli strumenti su un'intera base di codice.

Se ti va lasciaci una tua opinione

L'articolo ti è stato utile ed è tradotto correttamente?

ALTRI SUGGERIMENTI

Uso una combinazione di Cobertura, Checkstyle, (Ecl) Emma e Findbugs.

EclEmma è un plug-in Eclipse fantastico che mostra la copertura del codice colorando il sorgente java nell'editor ( screenshot ) - la copertura viene generata eseguendo un test JUnit. Questo è veramente utile quando stai cercando di capire quali linee sono coperte in una particolare classe, o se vuoi vedere solo quali linee sono coperte da un singolo test. Questo è molto più facile da usare e utile rispetto alla generazione di un rapporto e quindi alla consultazione del rapporto per vedere quali classi hanno una scarsa copertura.

Anche i plugin Checkstyle e Findbugs Eclipse sono utili, generano avvisi nell'editor durante la digitazione.

Maven2 ha plugin di report che funzionano con gli strumenti di cui sopra per generare report in fase di compilazione. Usiamo questo per ottenere rapporti generali sul progetto, che sono più utili quando vuoi numeri aggregati. Questi sono generati dai nostri build CI, che vengono eseguiti utilizzando Continuum .

Tutto quanto segue viene utilizzato e integrato facilmente sia nelle build Maven 2.x che in Eclipse / RAD 7:

  • Test - JUnit / TestNG
  • Analisi del codice - FindBugs, PMD
  • Copertura del codice - Clover

Inoltre, nelle nostre build Maven abbiamo:

  • JDepend
  • Controllo tag (TODO, FIXME, ecc.)

Inoltre, se stai utilizzando Maven 2.x, CodeHaus ha una raccolta di pratici plugin Maven nei loro Progetto Mojo .

Nota: Clover ha un'integrazione immediata con il server Bamboo CI (poiché sono entrambi prodotti Atlassian). Esistono anche plugin Bamboo per FindBugs, PMD e CheckStyle ma, come notato, anche il server CI Hudson gratuito ha questi.

Uso l'analisi statica integrata in IntelliJ IDEA. Perfetta integrazione.

Uso la copertura del codice integrata in Intellij IDEA (basata su EMMA). Ancora una volta, perfetta integrazione.

Questa soluzione integrata è affidabile, potente e facile da usare rispetto al collegamento di strumenti di vari fornitori.

Checkstyle è un altro che ho usato in un'azienda precedente ... è principalmente per il controllo dello stile , ma può anche eseguire alcune analisi statiche. Inoltre, Clover per la copertura del codice, sebbene tieni presente che non è uno strumento gratuito.

Stiamo usando FindBugs e Checkstyle e Clover per la copertura del codice.

Penso che sia importante avere una sorta di analisi statica, a supporto del tuo sviluppo. Sfortunatamente non è ancora ampiamente diffuso che questi strumenti siano importanti.

Utilizziamo FindBugs e JDepend integrati con Ant. Usiamo JUnit ma non stiamo usando alcuno strumento di copertura.

Non lo sto usando integrato in Rational Application Developer (l'IDE che sto usando per sviluppare applicazioni J2EE) perché mi piace come appare pulito quando si esegue javac nella console di Windows. : P

Ho avuto fortuna con Cobertura. È uno strumento di copertura del codice che può essere eseguito tramite il tuo script ant come parte della tua normale build e può essere integrato in Hudson.

Il nostro team utilizza PMD e Cobertura, in realtà i nostri progetti sono progetti maven ed è molto semplice includere plug-in per l'analisi del codice. La vera domanda sarebbe per il progetto specifico quale analisi devi usare, la mia opinione è che non puoi usare gli stessi plugin per ogni progetto.

nel nostro progetto utilizziamo Sonar di fronte a checkstyle, pmd .... insieme a CI (Bamboo, Hudson) otteniamo anche una bella storia della qualità della nostra fonte e di ciò che dirigiamo. Mi piace Sonar, perché sei uno strumento centrale nello stack CI che lo fa per te e puoi facilmente personalizzare le regole per ogni progetto.

Structure 101 è bravo nell'analisi del codice e nella ricerca delle dipendenze cicliche del pacchetto.

Sto cercando molte risposte per conoscere nuovi strumenti e consolidare queste conoscenze in un'unica domanda / discussione, quindi dubito che ci sarà una vera risposta a questa domanda.

La mia risposta alla mia domanda è che usiamo:

  • Findbugs per cercare errori comuni male / coding - eseguito da Maven e si integra facilmente in Eclipse
  • Cobertura per i nostri rapporti sulla copertura - eseguito da maven

Hudson ha anche un plugin per scanner di attività che mostrerà un conteggio dei tuoi TODO e FIXME, oltre a mostrare dove si trovano nei file di origine.

Tutti sono integrati con Maven 1.x nel nostro caso e collegati a Hudson, che esegue le nostre build al momento del check-in e cose extra notturne e settimanali. Le tendenze di Hudson rappresentano graficamente i nostri test JUnit, la copertura, i bug di ricerca e le attività aperte. C'è anche un plug-in Hudson che riporta e rappresenta graficamente i nostri avvisi di compilazione. Abbiamo anche diversi test delle prestazioni con i loro grafici delle prestazioni e dell'utilizzo della memoria nel tempo utilizzando anche il plug-in dei grafici di Hudson.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow