Checkstyle contro PMD

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.

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.

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".

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/

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

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

Dai un'occhiata a http://code.google.com/javadevtools/download-codepro.html

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.

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 ...

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".

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

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.

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.

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).

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>

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.

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.

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.

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