Gaya cek vs. PMD


86

Kami memperkenalkan alat analisis statis ke dalam sistem build untuk produk Java kami. Kami menggunakan Maven2 jadi integrasi Checkstyle dan PMD gratis. Namun, sepertinya ada banyak fungsi yang tumpang tindih antara kedua alat ini, dalam hal penerapan aturan gaya dasar.

Apakah ada keuntungan menggunakan keduanya? Saya tidak ingin mempertahankan 2 alat jika salah satunya akan berfungsi. Jika kita memilih salah satu, mana yang harus kita gunakan dan mengapa?

Kami juga berencana menggunakan FindBugs. Apakah ada alat analisis statis lain yang harus kita lihat?

Pembaruan: Konsensus tampaknya bahwa PMD lebih disukai daripada CheckStyle. Saya tidak melihat alasan kuat untuk menggunakan keduanya, dan saya tidak ingin mempertahankan 2 set file aturan, jadi kami mungkin akan menargetkan PMD secara eksklusif. Kami juga akan membawa FindBugs, dan mungkin, pada akhirnya, Macker untuk menegakkan aturan arsitektur.

Jawaban:


72

Anda pasti harus menggunakan FindBugs . Menurut pengalaman saya, rasio positif palsu sangat rendah, dan bahkan peringatan paling kritis yang dilaporkannya layak untuk ditangani sampai batas tertentu.

Untuk Checkstyle vs. PMD, saya tidak akan menggunakan Checkstyle karena ini hanya berkaitan dengan gaya. Menurut pengalaman saya, Checkstyle akan melaporkan banyak hal yang sama sekali tidak relevan. PMD di sisi lain juga dapat menunjukkan praktik pengkodean yang dipertanyakan dan hasilnya umumnya lebih relevan dan berguna.


49
1 untuk menambahkan rekomendasi Anda dari FindBugs. Namun, saya sangat tidak setuju dengan pendapat Anda tentang Checkstyle kecuali jika Anda adalah pengembang tunggal dengan gaya unik Anda sendiri. Untuk tim, menyetujui subset aturan umum yang masuk akal dan kemudian menggunakan alat otomatis seperti Checkstyle untuk memberlakukannya secara otomatis akan menghasilkan kode yang dapat dibaca oleh semua.
John Tobler

1
Meskipun tidak sempurna, FindBugs sejauh ini adalah yang terbaik. PMD dan checkstyle mengarahkan Anda ke praktik yang benar-benar buruk. Untuk dihindari dengan cara apa pun kecuali Anda tahu betul peringatan mana yang valid dan mana yang tidak.
DPM

Anehnya, saya mengalami pengalaman yang berlawanan dengan PMD vs Checkstyle. PMD sering melaporkan positif palsu jika itu adalah sesuatu yang tidak ditemukan oleh gaya cek atau Findbugs. 7 tahun bisa sangat berarti.
xenoterracide

38

Kedua perangkat lunak itu berguna. Checkstyle akan membantu Anda selama pemrograman dengan memeriksa gaya pengkodean Anda, misalnya braces, penamaan, dll. Hal-hal sederhana tetapi sangat banyak!

PMD akan membantu Anda dengan memeriksa aturan yang lebih rumit seperti selama desain kelas Anda, atau untuk masalah yang lebih khusus seperti mengimplementasikan fungsi klon dengan benar. Sederhananya, PMD akan memeriksa gaya pemrograman Anda

Namun, kedua perangkat lunak mengalami aturan serupa yang terkadang dijelaskan dengan buruk. Dengan konfigurasi yang buruk, Anda dapat memeriksa dua atau dua hal yang berlawanan, misalnya "Hapus konstruktor yang tidak berguna" dan "Selalu satu konstruktor".


10
Persis. IMHO, itu adalah 2 alat yang bertujuan untuk melakukan hal yang berbeda, jadi saya tidak yakin apakah keduanya sebanding. Jika Anda ingin menerapkan gaya pengkodean standar di antara tim pengembangan, gunakan Checkstyle. Jika Anda ingin menganalisis kode untuk masalah desain atau praktik pengkodean yang buruk, gunakan PMD.
aberrant80

24

Jika kita memilih salah satu, mana yang harus kita gunakan dan mengapa?

Alat-alat ini tidak bersaing tetapi saling melengkapi dan harus digunakan secara bersamaan.

Jenis konvensi (Checkstyle) adalah perekat yang memungkinkan orang untuk bekerja sama dan membebaskan kreativitas mereka alih-alih menghabiskan waktu dan energi untuk memahami kode yang tidak konsisten.

Contoh checkstyle:

  • Apakah ada javadoc tentang metode publik?
  • Apakah proyek mengikuti konvensi penamaan Sun?
  • Apakah kode ditulis dengan format yang konsisten?

sementara PMD mengingatkan Anda tentang praktik buruk:

  • Menangkap pengecualian tanpa melakukan apa pun
  • Memiliki kode mati
  • Terlalu banyak metode yang rumit
  • Penggunaan langsung implementasi, bukan antarmuka
  • Menerapkan metode hashcode () tanpa metode tidak sama dengan (Objek objek)

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


1
Saya setuju bahwa Checkstyle, lebih fokus pada format kode dan memaksa pengembang untuk mengikuti "Standar kode", tetapi juga dapat mendeteksi banyak praktik buruk, lihat di sini , dan ekstensi Checkstyle lebih mudah untuk pengembangan, tetapi saya setuju bahwa ia memiliki batasan dan tidak akan pernah mengatasi PMD dan FindBug.
Roman Ivanov

15

Kami menggunakan keduanya:

  • Periksa gaya untuk memastikan bahwa setiap orang dalam tim menulis kode dengan cara yang sama
  • PMD untuk menemukan area kode bermasalah dan target refactoring berikutnya


7

Jika Anda meninjau daftar aturan Checkstyle, PMD, dan Findbugs, Anda telah melihat bahwa ketiganya memberikan keluaran yang berharga dan ketiganya saling tumpang tindih dan juga membawa aturan unik mereka sendiri ke dalam tabel. Inilah mengapa alat seperti Sonar menggunakan ketiganya.

Meskipun demikian, Findbugs memiliki aturan yang paling spesifik atau khusus (misalnya, "Penangkapan yang meragukan dari IllegalMonitorStateException" - seberapa sering Anda akan mengalami hal itu?) Sehingga dapat digunakan dengan sedikit atau tanpa konfigurasi dan peringatannya harus ditanggapi dengan serius. Dengan Checkstyle dan PMD, aturan menjadi lebih umum dan terkait dengan gaya sehingga aturan tersebut hanya boleh digunakan dengan file konfigurasi kustom untuk menghindarkan tim dari longsoran umpan balik yang tidak relevan ("Tab char on line 5", "Tab char on line 6", "Tab char on line 7" ... Anda mendapatkan gambarnya). Mereka juga menyediakan alat yang ampuh untuk menulis aturan lanjutan Anda sendiri, misalnya aturan Checkstyle DescendentToken .

Saat menggunakan ketiganya (terutama dengan alat seperti Sonar), semuanya harus dikonfigurasi secara terpisah (membutuhkan setidaknya beberapa hari untuk mencakup semua aturan) sambil memperhatikan untuk mencegah duplikasi (ketiga alat mendeteksi bahwa hashCode () telah diganti dan sama dengan () tidak, misalnya).

Singkatnya, jika Anda menganggap analisis kode statis berharga, menolak nilai salah satu dari ketiganya tidak masuk akal, tetapi untuk menggunakan ketiganya, Anda harus menginvestasikan waktu untuk mengonfigurasinya untuk memberi Anda umpan balik yang berguna.


6

Sonar (http://www.sonarsource.org/) adalah platform terbuka yang sangat berguna untuk mengelola kualitas kode, dan mencakup Checkstyle, PMD, Findbugs, dan banyak lagi.

Ini juga menunjukkan bahwa ketiga alat memiliki hak untuk hidup ...


5

Kedua alat tersebut dapat dikonfigurasi dan dapat melakukan hampir semua hal yang sama. Yang mengatakan, jika kita berbicara tentang hal-hal out-of-the-box, ada banyak tumpang tindih, tetapi ada aturan / pemeriksaan yang berbeda juga. Misalnya, Checkstyle memiliki dukungan yang lebih kuat untuk memeriksa Javadoc dan menemukan angka ajaib, untuk menyebutkan pasangan. Selain itu, Checkstyle memiliki fitur "kontrol impor" yang terlihat mirip dengan fungsionalitas Macker (Saya belum pernah menggunakan Macker).

Jika ada hal yang penting bagi Anda yang tidak dilakukan oleh Checkstyle di luar kotak sedangkan PMD tidak, Anda dapat mempertimbangkan konfigurasi Checkstyle minimal dengan hanya pemeriksaan tersebut. Kemudian lakukan kebijakan yang tidak dapat dikembangkan oleh konfigurasi Checkstyle, cukup hapus centang saat Anda menerapkan fungsi serupa dengan, katakanlah, aturan PMD kustom.

Juga pertimbangkan bahwa jika Anda memutuskan bahwa fitur "kontrol impor" Checkstyle mencakup apa yang Anda inginkan dari Macker, maka Anda dapat menerapkan PMD / Checkstyle daripada PMD / Macker. Apa pun itu, ini adalah dua alat, tetapi dengan Checkstyle, Anda akan mendapatkan hal-hal yang tidak dilakukan PMD "secara gratis".


5

Checkstyle dan PMD keduanya bagus dalam memeriksa standar pengkodean dan mudah untuk diperluas. Tetapi PMD memiliki aturan tambahan untuk memeriksa kompleksitas siklomatik, kompleksitas Npath, dll. Yang memungkinkan Anda menulis kode yang sehat.

Keuntungan lain menggunakan PMD adalah CPD (Copy / Paste Detector). Ini menemukan duplikasi kode di seluruh proyek dan tidak dibatasi untuk JAVA. Ini juga berfungsi untuk JSP. Neal Ford memiliki presentasi yang bagus tentang Metrics Driven Agile Development , yang membahas tentang banyak alat yang berguna untuk Pengembangan Java / Java EE


4
Bagi siapa pun yang membaca ini ... checkstyle sekarang memiliki checkstyle.sourceforge.net/config_metrics.html checkstyle.sourceforge.net/config_duplicates.html
smp7d

4

Saya menemukan Checkstyle dan PMD adalah yang terbaik untuk memberlakukan masalah gaya dan bug pengkodean sederhana yang jelas. Meskipun saya telah menemukan bahwa saya suka menggunakan Eclipse dan semua peringatan yang diberikannya lebih baik untuk tujuan itu. Kami menerapkan hal-hal dengan menggunakan preferensi bersama dan menandainya sebagai kesalahan sebenarnya. Dengan begitu, mereka tidak pernah check-in sejak awal.

Apa yang sangat saya rekomendasikan dan antusias adalah menggunakan FindBugs. Karena bekerja pada tingkat bytecode, ia dapat memeriksa hal-hal yang tidak mungkin dilakukan pada tingkat sumber. Meskipun ia mengeluarkan banyak sampah, ia telah menemukan banyak bug aktual dan penting dalam kode kita.


4

Dan 10 tahun kemudian ... Pada 2018 saya menggunakan semuanya Checkstyle, PMD dan FindBugs.

Mulailah dengan FindBugs . Mungkin tambahkan PMD dan Checkstyle nanti.

Jangan pernah menegakkan aturan default secara membabi buta !

Langkah:

  • menjalankan satu alat dengan aturan default pada proyek yang memiliki banyak kode
  • sesuaikan aturan untuk proyek ini, beri komentar aturan yang tidak berguna dengan beberapa catatan
  • fokus pada aturan buah gantung rendah (NPE, pemeriksaan logger, pemeriksaan sumber daya tidak tertutup, ...)
  • melakukan beberapa perbaikan untuk aturan yang Anda anggap bermanfaat (satu per satu!)
  • lakukan ini untuk setiap alat tetapi tidak sekaligus!
  • ulangi proses ini

Idealnya setiap proyek dapat memiliki aturan terpisah. Saya suka menjalankan aturan melalui build (melalui plugin maven) dan gagal pada kesalahan aturan begitu saya tahu sebuah proyek melewati semua aturan yang saya tetapkan. Ini memaksa pengembang untuk mengambil tindakan, karena pelaporan saja tidak cukup . Sejak saat itu, proyek Anda cukup tahan banting dan Anda bahkan dapat menambahkan lebih banyak aturan nanti dan / atau menulis aturan khusus.


FYI, SpotBugs adalah "penerus spiritual FindBugs" , dan dokumentasi SpotBugs cukup bagus. Sejauh yang saya tahu, FindBugs belum diperbarui selama bertahun-tahun.
skomisa

Belum pernah mendengar tentang SpotBugs, mungkin karena FindBugs + fbcontrib sudah cukup lama, senang mengetahui ada beberapa pengganti
Christophe Roussy

Ada beberapa diskusi tentang itu di sini: news.ycombinator.com/item?id=12885549
Christophe

Perlu juga dicatat bahwa alat cenderung memiliki sensitivitas yang dapat dikonfigurasi. Misalnya saat memulai dengan FindBugs / SpotBugs, Anda mungkin perlu memilih ambang batas Tinggi untuk menangkap hanya bug yang paling serius, kemudian menurunkan ambang saat Anda memperbaiki semuanya.
ThrawnCA

@ThrawnCA ya, tetapi bahkan dengan sensitivitas: pada proyek besar terlalu banyak kesalahan yang ditemukan untuk diperbaiki dalam waktu yang wajar. Jadi yang saya lakukan adalah menambahkan aturan satu per satu, dimulai dengan buah gantung terendah seperti deteksi NP potensial, lalu beralih ke aturan seperti sumber daya yang tidak tertutup.
Christophe Roussy

3

Satu hal yang belum saya lihat sejauh ini adalah bahwa ada plugin untuk IDE yang akan memberlakukan aturan CheckStyle pada kode Anda, sedangkan plugin PMD hanya akan melaporkan pelanggaran. Misalnya, dalam proyek multi-situs melalui beberapa tim pemrograman, penting untuk secara aktif menegakkan standar, daripada hanya melaporkannya.

Kedua alat memiliki plugin yang tersedia untuk IntelliJ, NetBeans, dan Eclipse (menurut saya ini mencakup sebagian besar penggunaan). Saya tidak begitu familiar dengan NetBeans, jadi hanya bisa mengomentari IntelliJ dan Eclipse.

Bagaimanapun, plugin PMD untuk IntelliJ, dan Eclipse, akan menghasilkan laporan sesuai permintaan tentang pelanggaran PMD dalam basis kode proyek.

Plugin CheckStyle, di sisi lain, akan menyoroti pelanggaran dengan cepat, dan dapat (setidaknya untuk IntelliJ, saya memiliki lebih sedikit pengalaman dengan Eclipse) dikonfigurasi untuk secara otomatis mengonversi beberapa masalah (misalnya untuk 'OneStatementPerLine', akan menempatkan CR-LF antara pernyataan, untuk 'NeedBraces', akan menambahkan tanda kurung jika hilang, dll.). Jelas, hanya pelanggaran yang lebih sederhana yang dapat diperbaiki secara otomatis, tetapi ini masih membantu proyek lama, atau proyek yang berlokasi di beberapa lokasi.

'Sesuai permintaan' untuk PMD berarti bahwa pengembang harus secara sadar memutuskan untuk menjalankan laporan. Sedangkan pelanggaran Checkstyle secara otomatis dilaporkan kepada mereka saat berkembang. Sementara PMD memang mengandung seperangkat aturan yang lebih luas, menurut saya penegakan / pelaporan pelanggaran otomatis dalam IDE sepadan dengan kerumitan dalam mempertahankan 2 set aturan.

Jadi untuk setiap proyek yang saya kerjakan, kami menggunakan kedua alat, Checkstyle yang diterapkan di IDE, PMD dilaporkan di IDE, dan keduanya dilaporkan dan diukur dalam build (melalui Jenkins).


1
Ada juga cara untuk mengintegrasikannya dalam build dan membuatnya gagal jika terjadi pelanggaran (dengan maven misalnya). Saya telah melakukan ini untuk Checkstyle, PMD dan FindBugs. Seperti yang Anda katakan, pelaporan tidak cukup.
Christophe Roussy

3

Lihatlah qulice-maven-plugin yang menggabungkan Checkstyle, PMD, FindBugs dan beberapa penganalisis statis lainnya, dan pra-konfigurasi mereka. Keunggulan dari kombinasi ini adalah Anda tidak perlu mengonfigurasinya satu per satu di setiap proyek:

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

Bagaimana cara mengonfigurasinya untuk mendapatkan laporan (dalam beberapa format yang dapat digunakan)? Sekarang hanya meludah ke konsol bahkan jika saya mengkonfigurasi log4j. Saya melihat ada laporan bug yang mungkin terkait, tapi saya tidak yakin.
Adam Arold

Kami memikirkan hal yang sama tetapi untuk memperbaikinya saya perlu itu disorot dalam kode saya atau yang serupa. Setidaknya Anda settings.jarmembantu.
Adam Arold

2

Saya akan menggemakan komentar bahwa PMD adalah produk terbaru untuk pemeriksaan gaya / konvensi Java. Sehubungan dengan FindBugs, banyak grup pengembangan komersial menggunakan Coverity.


1

PMD adalah apa yang saya temukan lebih banyak orang rujuk. Checkstyle adalah apa yang dirujuk orang 4 tahun yang lalu, tetapi saya yakin PMD dipertahankan lebih terus-menerus dan apa yang dipilih oleh IDE / plugin lain untuk digunakan.


2
Benar pada tahun 2008, tetapi hari ini Checkstyle telah meningkat pesat.
barfuin

1

Saya baru saja mulai menggunakan Checkstyle dan PMD. Bagi saya, PMD lebih mudah untuk membuat aturan yang disesuaikan untuk hal-hal seperti apakah ada System.gc (), Runtime.gc (), selama Anda dapat menulis Query XPath yang juga tidak sulit sama sekali. Namun, PMD belum menunjukkan kepada saya bahwa ia memiliki fitur untuk menunjukkan nomor kolom. Jadi untuk hal-hal seperti batas kolom cek. Anda mungkin ingin menggunakan Checkstyle.


-2

PMD adalah alat terbaik jika dibandingkan dengan gaya cek. Checkstyles mungkin tidak memiliki kemampuan untuk menganalisis kode sementara PMD menawarkan banyak fitur untuk melakukannya! PMD offcourse belum merilis aturan untuk javadoc, komentar, indentasi, dll. Dan omong-omong saya berencana untuk menerapkan aturan ini ....... thanx


Satu hal yang baik tentang checkstyle adalah memungkinkan beberapa aturan fleksibel seperti RegexpSingleline ...
Jigar Shah
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.