Domanda

Stiamo introducendo strumenti di analisi statica nel sistema di compilazione per il nostro prodotto Java. Stiamo utilizzando Maven2, quindi Checkstyle e PMD l'integrazione è gratuita. Tuttavia sembra che vi sia una grande sovrapposizione di funzionalità tra questi due strumenti, in termini di applicazione delle regole di stile di base.

C'è un vantaggio nell'utilizzare entrambi? Non voglio mantenere 2 strumenti se uno funzionerà. Se scegliamo uno, quale dovremmo usare e perché?

Stiamo anche pianificando di utilizzare FindBugs. Ci sono altri strumenti di analisi statica che dovremmo esaminare?

Aggiornamento: il consenso sembra essere che PMD sia preferito su CheckStyle. Non vedo una solida ragione per usare entrambi, e non voglio mantenere 2 set di file di regole, quindi probabilmente mireremo esclusivamente a PMD. Porteremo anche FindBugs e forse, eventualmente, Macker per far rispettare le regole dell'architettura.

È stato utile?

Soluzione

Dovresti assolutamente utilizzare FindBugs . In base alla mia esperienza, il tasso di falsi positivi è molto basso e anche gli avvisi meno critici che segnala meritano di essere affrontati in una certa misura.

Per quanto riguarda Checkstyle vs. PMD, non userei Checkstyle poiché riguarda praticamente solo lo stile. Nella mia esperienza, Checkstyle riferirà su un sacco di cose che sono completamente irrilevanti. D'altra parte, PMD è anche in grado di evidenziare pratiche di codifica discutibili e il suo risultato è generalmente più pertinente e utile.

Altri suggerimenti

Entrambi i software sono utili. Checkstyle ti aiuterà durante la programmazione controllando il tuo stile di codifica ovvero parentesi graffe, denominazione ecc. Cose semplici ma molto numerose!

PMD ti aiuterà controllando regole più complicate come durante la progettazione delle tue lezioni, o per problemi più speciali come implementare correttamente la funzione clone. Semplicemente, PMD verificherà il tuo stile di programmazione

Tuttavia, entrambi i software soffrono di regole simili a volte male spiegate. Con una configurazione errata, puoi controllare le cose due o due cose opposte, vale a dire "Rimuovere costruttori inutili" e " Sempre un costruttore " ;.

  

Se scegliamo uno, quale dovremmo usare e perché?

Questi strumenti non sono in competizione ma sono complementari e dovrebbero essere usati contemporaneamente.

Il tipo di convenzione (Checkstyle) è la colla che consente alle persone di lavorare insieme e liberare la propria creatività invece di spendere tempo ed energia per comprendere il codice incoerente.

Esempi di stile di controllo:

  • Esiste javadoc sui metodi pubblici?
  • Il progetto segue le convenzioni di denominazione di Sun?
  • Il codice è stato scritto con un formato coerente?

mentre PMD ti ricorda le cattive pratiche:

  • Cattura un'eccezione senza fare nulla
  • Avere codice morto
  • Troppi metodi complessi
  • Uso diretto delle implementazioni anziché delle interfacce
  • Implementazione del metodo hashcode () senza il metodo non uguale a (Oggetto oggetto)

fonte: http://www.sonarsource.org/what-makes-checkstyle-pmd -findbugs-e-macker-complementare /

Usiamo entrambi:

  • Checkstyle per assicurarsi che tutti i membri del team scrivano il codice in un modo simile
  • PMD per trovare aree di codice problematiche e prossimi obiettivi di refactoring

Se il tuo luogo di utilizzo principale è lo sviluppo in eclissi, allora CodePro di Instantiances sarà il migliore. In precedenza era uno strumento commerciale, ma ora Google ha acquistato le istanze quindi Codeti analytix è ora gratuito.

Scopri http://code.google.com/javadevtools/download-codepro. html

Se hai esaminato gli elenchi di regole Checkstyle, PMD e Findbugs, hai notato che tutti e tre forniscono un output prezioso e tutti e tre si sovrappongono in una certa misura e portano anche le loro regole uniche al tavolo. Ecco perché strumenti come Sonar usano tutti e tre.

Detto questo, Findbugs ha le regole più specifiche o di nicchia (ad es. " Cattiva rilevazione di IllegalMonitorStateException " - con quale probabilità ti imbatterai in quello?) quindi è utilizzabile con poca o nessuna configurazione e i suoi avvertimenti dovrebbero essere presi sul serio. Con Checkstyle e PMD le regole sono più generali e relative allo stile, quindi dovrebbero essere utilizzate solo con i file di configurazione personalizzati per risparmiare il team da una valanga di feedback irrilevanti (" Tab char sulla riga 5 " ;, " Tab char sulla riga 6 " ;, " Tab char sulla riga 7 " ... ottieni l'immagine). Forniscono inoltre potenti strumenti per scrivere le tue regole avanzate, ad es. la regola Checka DescendentToken .

Quando si usano tutti e tre (specialmente con uno strumento come il Sonar), è necessario configurarli tutti separatamente (occorrono almeno alcuni giorni per coprire tutte le regole) prestando attenzione a prevenire la duplicazione (tutti e tre gli strumenti rilevano che hashCode ( ) è stato ignorato e uguale a (non, ad esempio).

In breve, se consideri preziosa l'analisi del codice statico, rifiutare il valore che uno dei tre fornisce non ha senso, ma per usare tutti e tre, devi investire tempo per configurarli per darti un feedback utilizzabile.

Sonar (http://www.sonarsource.org/) è una piattaforma aperta molto utile per gestire la qualità del codice e include Checkstyle, PMD, Findbugs e molto altro.

Questo indica anche che tutti e 3 gli strumenti hanno il diritto di esistere ...

Checkstyle e PMD sono entrambi bravi a controllare gli standard di codifica e sono facili da estendere. Ma PMD ha regole aggiuntive per verificare la complessità ciclomatica, la complessità di Npath, ecc., Che consente di scrivere codice integro.

Un altro vantaggio dell'utilizzo di PMD è CPD (Copy / Paste Detector): trova la duplicazione del codice tra i progetti e non è vincolato a JAVA, ma funziona anche con JSP. Neal Ford ha una buona presentazione su Metrics Driven Agile Development , che parla di molti strumenti utili per lo sviluppo EE Java / Java

Trovo che Checkstyle e PMD siano i migliori per applicare problemi di stile e semplici ovvi bug di codifica. Anche se ho scoperto che mi piace usare Eclipse e tutti gli avvisi che fornisce meglio a tale scopo. Facciamo rispettare le cose utilizzando le preferenze condivise e contrassegnandole come errori effettivi. In questo modo, non vengono mai registrati in primo luogo.

Quello che consiglio vivamente e con entusiasmo è l'uso di FindBugs. Poiché funziona a livello di bytecode, può verificare cose impossibili a livello di sorgente. Mentre sputa la sua giusta dose di giunche, ha trovato molti bug reali e importanti nel nostro codice.

Entrambi gli strumenti sono configurabili e possono fare praticamente le stesse cose. Detto questo, se stiamo parlando di cose pronte all'uso, ci sono molte sovrapposizioni, ma ci sono anche regole / controlli distinti. Ad esempio, Checkstyle ha un supporto più forte per il controllo di Javadoc e la ricerca di numeri magici, per nominarne un paio. Inoltre, Checkstyle ha un "controllo di importazione" caratteristica che sembra simile alla funzionalità di Macker (non ho usato Macker).

Se ci sono cose importanti per te che Checkstyle fa immediatamente e PMD no, potresti considerare una configurazione Checkstyle minima con solo quei controlli. Quindi istituisci una politica che la configurazione di Checkstyle non può aumentare, rimuovi semplicemente i controlli mentre implementi funzionalità simili con, diciamo, regole PMD personalizzate.

Considera anche che se decidi che il Checkstyle " import control " La funzione copre ciò che volevi da Macker, quindi potresti implementare PMD / Checkstyle invece di PMD / Macker. In entrambi i casi si tratta di due strumenti, ma con Checkstyle, otterresti le cose che PMD non fa "out-of-the-box" gratuitamente. & Quot;

Un punto che non ho visto finora è che ci sono plugin per IDE che imporranno le regole di CheckStyle sul tuo codice, mentre i plugin PMD segnaleranno solo le violazioni. Ad esempio, in un progetto multi-sito su più team di programmazione, è importante applicare attivamente gli standard, piuttosto che riferire solo su di essi.

Entrambi gli strumenti hanno plug-in disponibili per IntelliJ, NetBeans ed Eclipse (a mio avviso questo copre la maggior parte dell'utilizzo). Non ho familiarità con NetBeans, quindi posso solo commentare IntelliJ ed Eclipse.

In ogni caso, i plugin PMD per IntelliJ ed Eclipse genereranno rapporti su richiesta sulle violazioni di PMD all'interno della base di codice del progetto.

I plugin CheckStyle, d'altra parte, metteranno in evidenza le violazioni al volo e possono (almeno per IntelliJ, ho meno esperienza con Eclipse) essere configurato per convertire automaticamente alcuni problemi (ad esempio per "OneStatementPerLine", posizionerà CR-LF tra le istruzioni, per "NeedBraces", aggiungerà parentesi graffe dove mancano, ecc.). Ovviamente, solo le violazioni più semplici possono essere riparate automaticamente, ma è ancora un aiuto su progetti legacy o su progetti situati su più posizioni.

"Su richiesta" per PMD significa che lo sviluppatore deve decidere consapevolmente di eseguire il report. Considerando che le violazioni di Checkstyle vengono automaticamente segnalate a loro mentre si sviluppano. Mentre PMD contiene contiene un set di regole più ampio, nella mia mente la messa in atto / segnalazione automatica delle violazioni negli IDE vale la seccatura di mantenere 2 set di regole.

Quindi per tutti i progetti a cui lavoro, utilizziamo entrambi gli strumenti, Checkstyle applicato nell'IDE, PMD riportato nell'IDE e entrambi riportati e misurati nelle build (tramite Jenkins).

E 10 anni dopo ... Nel 2018 li uso tutti Checkstyle, PMD e FindBugs.

Inizia con Trova bug . Forse aggiungere PMD e Checkstyle più tardi.

Non applicare mai ciecamente le regole predefinite !

Passi:

  • esegui uno strumento con regole predefinite su un progetto che ha molto codice
  • adatta le regole a questo progetto, commenta regole inutili con alcune note
  • attenzione alle regole sui frutti sospesi (NPE, controlli del logger, controlli delle risorse non chiusi, ...)
  • esegui alcune correzioni per le regole che ritieni utili (una alla volta!)
  • fallo per ogni strumento ma non tutti in una volta!
  • ripeti questo processo

Idealmente ogni progetto può avere regole separate. Mi piace eseguire le regole tramite la build (tramite plug-in Maven) e fallire sugli errori delle regole una volta che so che un progetto ha superato tutte le regole che ho definito. Ciò costringe gli sviluppatori ad agire, perché i rapporti non sono sufficienti . Da quel momento in poi il tuo progetto è praticamente a prova di proiettile e potresti persino aggiungere più regole in seguito e / o scrivere regole personalizzate.

Dai un'occhiata a qulice-maven-plugin che combina Checkstyle, PMD, FindBugs e alcuni altri analizzatori statici e li preconfigura. Il bello di questa combinazione è che non è necessario configurarli singolarmente in ogni progetto: 

<plugin>
  <groupId>com.qulice</groupId>
  <artifactId>qulice-maven-plugin</artifactId>
  <version>0.15</version>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Vorrei fare eco al commento che PMD è il prodotto più attuale per il controllo di stile / convenzione Java. Per quanto riguarda FindBugs, molti gruppi di sviluppo commerciale utilizzano Coverity.

Ho appena iniziato a usare Checkstyle e PMD. Per me, PMD è più facile creare regole personalizzate per cose come l'esistenza di System.gc (), Runtime.gc (), purché sia ??possibile scrivere la query XPath, che non è per nulla difficile. Tuttavia, PMD non mi ha mostrato che ha la funzione di mostrare il numero di colonna. Quindi per cose come controllare i limiti delle colonne. Potresti voler usare Checkstyle.

PMD è ciò che trovo più persone a cui si riferiscono. Checkstyle era ciò a cui la gente si riferiva 4 anni fa, ma credo che PMD sia mantenuto più continuamente e con quali altri IDE / plugin scelgono di lavorare.

PMD è lo strumento migliore se confrontato con gli stili di controllo. Checkstyles potrebbe non essere in grado di analizzare il codice mentre PMD offre molte funzionalità per farlo! Fuori sede PMD non ha rilasciato regole per javadoc, commenti, rientri e così via. E comunque sto programmando di implementare queste regole ....... grazie

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top