Checkstyle contro PMD


86

Stiamo introducendo strumenti di analisi statica nel sistema di compilazione per il nostro prodotto Java. Stiamo utilizzando Maven2 quindi l' integrazione di Checkstyle e PMD è gratuita. Tuttavia sembra che ci 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 ne scegliamo uno, quale dovremmo usare e perché?

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

Aggiornamento: il consenso sembra essere che PMD è preferito a CheckStyle. Non vedo una buona ragione per usarli entrambi e non voglio mantenere 2 set di file di regole, quindi probabilmente mireremo esclusivamente a PMD. Introdurremo anche FindBugs e forse, eventualmente, Macker per applicare le regole architetturali.

Risposte:


71

Dovresti assolutamente usare FindBugs . Nella mia esperienza, il tasso di falsi positivi è molto basso e anche gli avvertimenti meno critici che riporta vale la pena affrontare in una certa misura.

Per quanto riguarda Checkstyle contro PMD, non userei Checkstyle poiché si tratta praticamente solo di stile. Nella mia esperienza, Checkstyle riferirà su un sacco di cose che sono completamente irrilevanti. Il PMD d'altra parte è anche in grado di segnalare pratiche di codifica discutibili e il suo output è generalmente più pertinente e utile.


49
+1 per l'aggiunta della tua raccomandazione di FindBugs. Tuttavia, non sono assolutamente d'accordo con la tua opinione su Checkstyle a meno che tu non sia uno sviluppatore solitario con il tuo stile peculiare. Per i team, concordare un sottoinsieme ragionevole comune di regole e quindi utilizzare uno strumento automatizzato come Checkstyle per applicarle automaticamente si traduce in un codice leggibile da tutti.
John Tobler

1
Sebbene non sia perfetto, FindBugs è di gran lunga il migliore. PMD e checkstyle ti indirizzano verso pratiche vere e proprie. Da evitare a tutti i costi a meno che non si sappia molto bene quali avvertenze sono valide e quali no.
DPM

Stranamente ho avuto l'esperienza esattamente opposta con PMD vs Checkstyle. PMD segnala spesso falsi positivi se è qualcosa di stile di controllo o Findbugs non ha trovato. 7 anni possono contare molto però.
xenoterracide

38

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

PMD ti aiuterà controllando regole più complicate come durante la progettazione delle tue classi, 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 spiegate male. Con una cattiva configurazione, puoi controllare le cose due o due cose opposte, cioè "Rimuovi costruttori inutili" e "Sempre un costruttore".


10
Esattamente. IMHO, sono 2 strumenti che mirano a fare cose diverse, quindi non sono sicuro che siano paragonabili. Se vuoi applicare uno stile di codifica standard a un team di sviluppo, usa Checkstyle. Se desideri analizzare il codice per problemi di progettazione o cattive pratiche di codifica, utilizza PMD.
aberrant80

24

Se ne scegliamo uno, quale dovremmo usare e perché?

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

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

Esempi di stile di controllo:

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

mentre PMD ti ricorda le cattive pratiche:

  • Catturare un'eccezione senza fare nulla
  • Avere codice morto
  • Troppi metodi complessi
  • Uso diretto delle implementazioni invece delle interfacce
  • Implementazione del metodo hashcode () senza il metodo not equals (Object object)

fonte: http://www.sonarsource.org/what-makes-checkstyle-pmd-findbugs-and-macker-complementary/


1
Sono d'accordo sul fatto che Checkstyle si concentri maggiormente sul formato del codice e costringa lo sviluppatore a seguire lo "standard del codice", ma potrebbe anche rilevare molte cattive pratiche, dai un'occhiata qui e l'estensione di Checkstyle è più facile per lo sviluppo, ma sono d'accordo che ha dei limiti e non supererà mai PMD e FindBug.
Roman Ivanov

15

Usiamo entrambi:

  • Controlla lo stile per assicurarti che tutti i membri del team scrivano il codice in modo simile
  • PMD per trovare aree di codice problematiche e obiettivi di refactoring successivo


7

Se hai esaminato gli elenchi di regole Checkstyle, PMD e Findbugs, hai visto che tutti e tre forniscono un output prezioso e tutti e tre si sovrappongono in una certa misura e portano anche le proprie regole uniche al tavolo. Questo è il motivo per cui strumenti come Sonar li utilizzano tutti e tre.

Detto questo, Findbugs ha le regole più specifiche o di nicchia (ad esempio "Cattura dubbia di IllegalMonitorStateException" - quanto spesso è probabile che lo incontri?) 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 legate allo stile, quindi dovrebbero essere utilizzate solo con file di configurazione personalizzati per evitare al team una valanga di feedback irrilevanti ("Tab char on line 5", "Tab char on line 6", "Tab char on line 7" ... ottieni l'immagine). Forniscono anche potenti strumenti per scrivere le tue regole avanzate, ad esempio il Checkstyle DescendentToken regola .

Quando si utilizzano tutti e tre (specialmente con uno strumento come Sonar), tutti dovrebbero essere configurati separatamente (richiede almeno alcuni giorni per coprire tutte le regole) prestando attenzione a prevenire la duplicazione (tutti e tre gli strumenti rilevano che hashCode () è stato sovrascritto e uguale a () no, per esempio).

In sintesi, se si considera preziosa l'analisi statica del codice, non ha senso rifiutare il valore fornito da uno qualsiasi dei tre, ma per utilizzarli tutti e tre, è necessario investire tempo per configurarli in modo da fornire un feedback utilizzabile.


6

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

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


5

Entrambi gli strumenti sono configurabili e possono fare quasi le stesse cose. Detto questo, se parliamo di cose pronte all'uso, c'è molta sovrapposizione, ma ci sono anche regole / controlli distinti. Ad esempio, Checkstyle ha un supporto più forte per controllare Javadoc e trovare numeri magici, per citarne un paio. Inoltre, Checkstyle ha una funzione di "controllo dell'importazione" che sembra simile alla funzionalità di Macker (non ho usato Macker).

Se ci sono cose importanti per te che Checkstyle fa fuori dagli schemi e che PMD non fa, potresti prendere in considerazione una configurazione Checkstyle minima con solo quei controlli. Quindi istituire una politica in base alla quale la configurazione Checkstyle non può crescere, è sufficiente rimuovere i controlli quando si implementano funzionalità simili con, ad esempio, regole PMD personalizzate.

Considera inoltre che se decidi che la funzionalità "controllo importazione" di Checkstyle copre ciò che desideri da Macker, potresti implementare PMD / Checkstyle invece di PMD / Macker. In entrambi i casi sono due strumenti, ma con Checkstyle, otterrai le cose che PMD non fa immediatamente "gratuitamente".


5

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), che rileva la duplicazione del codice tra i progetti e non è vincolato a JAVA. Funziona anche per JSP. Neal Ford ha una buona presentazione su Metrics Driven Agile Development , che parla di molti strumenti utili per lo sviluppo Java / Java EE



4

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

Quello che consiglio vivamente ed entusiasticamente è usare FindBugs. Poiché funziona a livello di bytecode, può controllare cose impossibili a livello di sorgente. Mentre sputa la sua giusta quota di giunche, ha trovato molti bug effettivi e importanti nel nostro codice.


4

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

Inizia con FindBugs . Forse aggiungi PMD e Checkstyle più tardi.

Non applicare mai ciecamente le regole predefinite !

Passaggi:

  • esegui uno strumento con regole predefinite su un progetto che ha molto codice
  • adattare le regole a questo progetto, commentare regole inutili con alcune note
  • concentrarsi sulle regole dei frutti a bassa impiccagione (NPE, controlli logger, controlli delle risorse non chiuse, ...)
  • esegui alcune correzioni per le regole che ritieni utili (una alla volta!)
  • fallo per ogni strumento ma non tutto in una volta!
  • ripetere questo processo

Idealmente ogni progetto può avere regole separate. Mi piace eseguire le regole tramite la build (tramite plug-in di maven) e fallire sugli errori delle regole una volta che so che un progetto supera tutte le regole che ho definito. Ciò costringe gli sviluppatori ad agire, perché la segnalazione non è sufficiente . 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.


Cordiali saluti, SpotBugs è il "successore spirituale di FindBugs" e la documentazione di SpotBugs è piuttosto buona. Per quanto ne so FindBugs non è stato aggiornato da anni.
skomisa

Mai sentito parlare di SpotBugs, probabilmente perché FindBugs + fbcontrib è stato sufficiente per molto tempo, bene sapere che c'è qualche sostituto
Christophe Roussy

C'è qualche discussione al riguardo qui: news.ycombinator.com/item?id=12885549
Christophe Roussy,

Vale anche la pena notare che gli strumenti tendono ad avere una sensibilità configurabile. Ad esempio, quando si inizia con FindBugs / SpotBugs potrebbe essere necessario scegliere una soglia alta per rilevare solo i bug più gravi, quindi abbassare la soglia quando si risolvono le cose.
ThrawnCA

@ThrawnCA si ma anche con sensibilità: su un progetto di grandi dimensioni si troveranno troppi errori da correggere in un ragionevole lasso di tempo. Quindi quello che faccio invece è aggiungere una regola alla volta, iniziando con i frutti più bassi come il potenziale rilevamento di NP, quindi passare a regole come le risorse non chiuse.
Christophe Roussy

3

Un punto che non ho visto finora è che ci sono plugin per IDE che applicheranno set di regole 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 limitarsi a riferirli.

Entrambi gli strumenti hanno plugin disponibili per IntelliJ, NetBeans ed Eclipse (a mio avviso questo copre la maggior parte dell'utilizzo). Non conosco NetBeans, quindi posso solo commentare IntelliJ ed Eclipse.

Ad ogni modo, i plug-in 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, evidenzieranno le violazioni al volo e possono (almeno per IntelliJ, ho meno esperienza con Eclipse) essere configurati per convertire automaticamente alcuni problemi (ad esempio per 'OneStatementPerLine', inserirà CR-LF tra le istruzioni, per 'NeedBraces', aggiungerà parentesi graffe dove mancano, ecc.). Ovviamente, solo le violazioni più semplici possono essere corrette automaticamente, ma è comunque un aiuto per i progetti legacy o per i progetti situati in più posizioni.

"Su richiesta" per PMD significa che lo sviluppatore deve decidere consapevolmente di eseguire il rapporto. Mentre le violazioni di Checkstyle vengono segnalate automaticamente mentre si sviluppano. Mentre PMD lo fa contenere un più ampio set di regole, nella mia mente l'enforecement automatica / segnalazione di violazioni in IDE vale la fatica di mantenere 2 set di regole.

Quindi, per qualsiasi progetto su cui lavoro, utilizziamo entrambi gli strumenti, Checkstyle applicato nell'IDE, PMD riportato nell'IDE, ed entrambi segnalati e misurati in build (tramite Jenkins).


1
Ci sono anche modi per integrarlo nella build e farlo fallire in caso di violazione (con Maven per esempio). L'ho fatto per Checkstyle, PMD e FindBugs. Come hai detto, la segnalazione non è sufficiente.
Christophe Roussy

3

Dai un'occhiata al plugin qulice-maven che combina insieme Checkstyle, PMD, FindBugs e alcuni altri analizzatori statici e li preconfigura. Il bello di questa combinazione è che non è necessario configurarli individualmente 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>

Come lo configuro per ottenere un rapporto (in qualche formato utilizzabile)? Ora lo sputa solo alla console anche se configuro log4j. Vedo che c'è una segnalazione di bug che potrebbe essere correlata, ma non ne sono sicuro.
Adam Arold

Stiamo pensando la stessa cosa, ma per risolverlo ho bisogno che sia evidenziato nel mio codice o qualcosa di simile. Almeno il tuo settings.jaraiuto.
Adam Arold

2

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


1

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


2
Vero nel 2008, ma oggi Checkstyle ha acquisito molta velocità.
barfuin

1

Ho appena iniziato a utilizzare Checkstyle e PMD. Per me, PMD è più facile creare regole personalizzate per cose come se esistano System.gc (), Runtime.gc (), a patto che tu possa scrivere la query XPath che non è affatto difficile. Tuttavia, PMD non mi ha mostrato che ha la funzione per mostrare il numero di colonna. Quindi per cose come controllare i limiti delle colonne. Potresti voler usare Checkstyle.


-2

PMD è lo strumento migliore se confrontato con gli stili di controllo. Checkstyles potrebbe non avere la capacità di analizzare il codice mentre PMD offre molte funzionalità per farlo! Offcourse PMD non ha rilasciato regole per javadoc, commenti, rientranze e così via. E a proposito, ho intenzione di implementare queste regole ....... grazie


Una cosa buona dello stile di controllo è che consente alcune regole flessibili come RegexpSingleline ...
Jigar Shah
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.