Checkstyle vs PMD

Java ürünümüz için derleme sistemine statik analiz araçları ekliyoruz. Maven2 kullanıyoruz, bu nedenle Checkstyle ve PMD entegrasyonu ücretsiz geliyor. Bununla birlikte, temel stil kurallarının uygulanması açısından bu iki araç arasında işlevsellikte büyük bir örtüşme var gibi görünüyor.

Bunların her ikisini de kullanmanın bir faydası var mı? Biri çalışacaksa 2 araç bulundurmak istemiyorum. Birini seçersek hangisini kullanmalıyız ve neden?

Ayrıca FindBugs kullanmayı planlıyoruz. Bakmamız gereken başka statik analiz araçları var mı?

Güncelleme: Konsensus, PMD'nin CheckStyle'a tercih edildiği gibi görünüyor. Her ikisini de kullanmak için sağlam bir neden görmüyorum ve 2 grup kural dosyası tutmak istemiyorum, bu yüzden muhtemelen sadece PMD'yi hedefleyeceğiz. Mimari kuralları uygulamak için FindBugs ve belki de sonunda Macker'ı da getireceğiz.

Kesinlikle FindBugs kullanmalısınız . Tecrübelerime göre, yanlış pozitif oranı çok düşük ve rapor ettiği en az kritik uyarılar bile bir dereceye kadar ele alınmaya değer.

Checkstyle ve PMD'ye gelince, Checkstyle'ı kullanmam çünkü bu sadece stil ile ilgilidir. Tecrübelerime göre, Checkstyle tamamen alakasız olan bir sürü şeyi rapor edecek. Öte yandan PMD, şüpheli kodlama uygulamalarına da işaret edebilir ve çıktısı genellikle daha alakalı ve yararlıdır.

Her iki yazılım da kullanışlıdır. Checkstyle, kodlama stilinizi kontrol ederek programlamanız sırasında size yardımcı olacaktır , örn. Kaşlı ayraçlar, adlar vb. Basit şeyler ama çok sayıda!

PMD, sınıflarınızın tasarımı sırasında olduğu gibi daha karmaşık kuralları veya klon işlevini doğru bir şekilde uygulamak gibi daha özel sorunları kontrol ederek size yardımcı olacaktır. Basitçe, PMD programlama stilinizi kontrol eder

Ancak, her iki yazılım da benzer kurallardan muzdariptir, bazen kötü açıklanır. Kötü bir konfigürasyonla, her şeyi iki veya iki zıt şeyi kontrol edebilirsiniz, örneğin "Yararsız kurucuları kaldır" ve "Her zaman bir kurucu".

Birini seçersek hangisini kullanmalıyız ve neden?

Bu araçlar birbiriyle rekabet etmiyor ancak birbirini tamamlıyor ve aynı anda kullanılmalıdır.

Kural türü (Checkstyle), tutarsız kodları anlamak için zaman ve enerji harcamak yerine, insanların birlikte çalışmasını ve yaratıcılıklarını serbest bırakmasını sağlayan yapıştırıcıdır.

Kontrol stili örnekleri:

• Herkese açık yöntemlerde javadoc var mı?
• Proje, Sun adlandırma kurallarını takip ediyor mu?
• Kod tutarlı bir formatta mı yazılıyor?

PMD size kötü uygulamaları hatırlatırken:

• Hiçbir şey yapmadan bir istisna yakalamak
• Ölü koda sahip olmak
• Çok fazla karmaşık yöntem
• Arayüzler yerine uygulamaların doğrudan kullanımı
• Not equals (Object nesnesi) yöntemi olmadan hashcode () yöntemini uygulama

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

İkisini de kullanıyoruz:

• Ekipteki herkesin benzer şekilde kod yazdığından emin olmak için stili kontrol edin
• PMD sorunlu kod alanlarını ve sonraki yeniden düzenleme hedeflerini bulmak için

Birincil kullanım yeriniz tutulmada geliştirme sırasında ise, Instantiations'tan CodePro en iyisi olacaktır. Daha önce ticari bir araçtı, ancak şimdi Google Instantiations satın aldı, böylece CodePro analytix artık ücretsiz.

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

Checkstyle, PMD ve Findbugs kural listelerini incelediyseniz, üçünün de değerli çıktılar sağladığını ve üçünün de bir dereceye kadar örtüştüğünü ve ayrıca tabloya kendi benzersiz kurallarını getirdiğini gördünüz. Bu nedenle Sonar gibi araçlar üçünü de kullanır.

Bununla birlikte, Findbugs en özel veya niş kurallara sahiptir (örn. "IllegalMonitorStateException şüpheli yakalama" - bununla ne sıklıkla karşılaşacaksınız?), Bu nedenle çok az veya hiç yapılandırma olmadan kullanılabilir ve uyarıları ciddiye alınmalıdır. Checkstyle ve PMD ile kurallar daha geneldir ve stille ilişkilidir, bu nedenle sadece özel yapılandırma dosyalarıyla birlikte kullanılmaları, ekibi ilgisiz bir geri bildirim çığlığından kurtarmak için kullanılmalıdır ("5. satırdaki Tab karakter", "6. satırdaki sekme karakteri", "7. satırdaki sekme karakteri" ... resmi anladınız). Ayrıca, Checkstyle DescendentToken kuralı gibi kendi gelişmiş kurallarınızı yazmak için güçlü araçlar sağlarlar .

Üçünü de kullanırken (özellikle Sonar gibi bir araçla), bunların tümü ayrı ayrı yapılandırılmalıdır (tüm kuralları kapsaması en az birkaç gün sürer) ve yinelemeyi önlemeye dikkat ederken (üç araç da hashCode () geçersiz kılınır ve eşittir () değil, örneğin).

Özetle, statik kod analizinin değerli olduğunu düşünüyorsanız, üçünden herhangi birinin sağladığı değeri reddetmenin bir anlamı yoktur, ancak üçünü de kullanmak için, bunları size kullanılabilir geri bildirim sağlayacak şekilde yapılandırmak için zaman ayırmanız gerekir.

Sonar (http://www.sonarsource.org/), kod kalitesini yönetmek için çok kullanışlı bir açık platformdur ve Checkstyle, PMD, Findbugs ve çok daha fazlasını içerir.

Bu aynı zamanda 3 aracın da var olma hakkına sahip olduğunu gösterir ...

Her iki araç da yapılandırılabilir ve hemen hemen aynı şeyleri yapabilir. Bununla birlikte, kullanıma hazır şeylerden bahsediyorsak, çok fazla örtüşme vardır, ancak farklı kurallar / kontroller de vardır. Örneğin, Checkstyle, bir çifti adlandırmak için Javadoc'u kontrol etmek ve sihirli sayıları bulmak için daha güçlü desteğe sahiptir. Ek olarak, Checkstyle, Macker'ın işlevselliğine benzeyen bir "içe aktarma kontrolü" özelliğine sahiptir (Macker'ı kullanmadım).

Sizin için önemli olan ve Checkstyle'ın PMD'nin yapmadığı kutudan çıkar çıkmaz yaptığı şeyler varsa, yalnızca bu kontrolleri içeren minimal bir Checkstyle yapılandırması düşünebilirsiniz. Ardından, Checkstyle yapılandırmasının büyüyemeyeceğine dair bir politika oluşturun, örneğin özel PMD kurallarıyla benzer işlevselliği uyguladığınız için kontrolleri kaldırın.

Ayrıca, Checkstyle "içe aktarma denetimi" özelliğinin Macker'dan istediğinizi kapsadığına karar verirseniz, PMD / Macker yerine PMD / Checkstyle uygulayabileceğinizi de göz önünde bulundurun. Her iki durumda da bu iki araçtır, ancak Checkstyle ile PMD'nin kutudan çıktığı gibi yapmadığı şeyleri "ücretsiz" alırsınız.

Checkstyle ve PMD, kodlama standartlarını kontrol etmede iyidir ve genişletmeleri kolaydır. Ancak PMD'nin döngüsel karmaşıklığı, Npath karmaşıklığını vb. Kontrol etmek için ek kuralları vardır ve bu da sağlıklı kod yazmanıza olanak tanır.

PMD kullanmanın bir başka avantajı da CPD'dir (Kopyala / Yapıştır Dedektörü) Projeler arasında kod çoğaltmasını bulur ve JAVA ile sınırlı değildir. JSP için de çalışır. Neal Ford, Java / Java EE Geliştirme için yararlı olan birçok araçtan bahseden Metrics Driven Agile Development hakkında iyi bir sunum yaptı.

Checkstyle ve PMD'nin stil sorunlarını ve basit açık kodlama hatalarını zorlamak için en iyisi olduğunu düşünüyorum. Eclipse kullanmayı sevdiğimi ve tüm uyarıları bu amaçla daha iyi sağladığını fark etsem de. Öğeleri, paylaşılan tercihleri ​​kullanarak ve bunları gerçek hatalar olarak işaretleyerek uygularız. Bu şekilde, ilk etapta asla kontrol edilmezler.

Şiddetle ve şevkle tavsiye edeceğim şey FindBugs kullanmaktır. Bayt kodu seviyesinde çalıştığı için, imkansız olan şeyleri kaynak seviyesinde kontrol edebilir. Adil hurdalık payını ortaya çıkarırken, kodumuzda birçok gerçek ve önemli hata buldu.

Ve 10 yıl sonra ... 2018'de hepsini Checkstyle, PMD ve FindBugs kullanıyorum.

FindBugs ile başlayın . Belki PMD ve Checkstyle'ı daha sonra ekleyebilirsiniz.

Varsayılan kuralları asla körü körüne uygulamayın !

Adımlar:

• Çok fazla koda sahip bir projede varsayılan kurallara sahip bir araç çalıştırın
• kuralları bu projeye uyarlayın, yararsız kuralları bazı notlarla yorumlayın
• Düşük asılı meyve kurallarına odaklanın (NPE, kaydedici kontrolleri, kapatılmamış kaynak kontrolleri, ...)
• Değerli bulduğunuz kurallar için bazı düzeltmeler yapın (teker teker!)
• bunu her araç için yapın ama hepsini aynı anda yapmayın!
• bu işlemi tekrar et

İdeal olarak her projenin ayrı kuralları olabilir. Kuralları derleme yoluyla (maven eklentileri aracılığıyla) çalıştırmayı seviyorum ve bir projenin tanımladığım tüm kuralları geçtiğini bildiğimde kural hatalarında başarısız oluyorum. Bu, geliştiricileri harekete geçmeye zorlar çünkü raporlama yeterli değildir . Bu noktadan itibaren projeniz hemen hemen kurşun geçirmezdir ve daha sonra daha fazla kural ekleyebilir ve / veya özel kurallar yazabilirsiniz.

Şimdiye kadar görmediğim bir nokta, IDE'ler için kodunuz üzerinde CheckStyle kural setlerini uygulayacak eklentilerin olduğu, PMD eklentilerinin ise yalnızca ihlalleri rapor edeceği. Örneğin, birkaç programlama ekibinin yer aldığı çok bölgeli bir projede, standartları yalnızca raporlamaktan ziyade aktif bir şekilde uygulamak önemlidir.

Her iki aracın da IntelliJ, NetBeans ve Eclipse için kullanılabilen eklentileri vardır (benim görüşüme göre bu çoğu kullanımı kapsar). NetBeans'e aşina değilim, bu yüzden yalnızca IntelliJ ve Eclipse hakkında yorum yapabilirim.

Her neyse, IntelliJ ve Eclipse için PMD eklentileri , proje kod tabanı içindeki PMD ihlalleri hakkında talep üzerine raporlar oluşturacaktır .

Öte yandan CheckStyle eklentileri, ihlalleri anında vurgular ve (en azından IntelliJ için Eclipse ile daha az deneyimim var) bazı sorunları otomatik olarak dönüştürmek için yapılandırılabilir (örneğin, 'OneStatementPerLine' için CR-LF ifadeler arasında, 'NeedBraces' için eksik oldukları yerlere parantez ekleyecektir, vb.). Açıkçası, yalnızca daha basit ihlaller otomatik olarak düzeltilebilir, ancak bu yine de eski projelerde veya birkaç yerde bulunan projelerde yardımcı olur.

PMD için 'talep üzerine', geliştiricinin bilinçli olarak raporu çalıştırmaya karar vermesi gerektiği anlamına gelir. Oysa Checkstyle ihlalleri geliştikçe otomatik olarak onlara rapor edilir. PMD iken yaptığı daha kapsamlı bir kural setine içerirler, zihnimde otomatik enforecement / IDE ihlallerin raporlama değerinde kurallarının 2 takım sürdürmenin güçlük olduğunu.

Bu yüzden biz de araçları kullanmak, üzerinde çalışmak herhangi projeler için, Checkstyle ıde zorlanan, PMD IDE bildirilen ve hem yapılarında (Jenkins aracılığıyla) bildirilen ve ölçtü.

Checkstyle, PMD, FindBugs ve diğer birkaç statik çözümleyiciyi bir araya getiren ve bunları önceden yapılandıran qulice-maven eklentisine bir göz atın . Bu kombinasyonun güzelliği, bunları her projede ayrı ayrı yapılandırmanıza gerek olmamasıdır:

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

PMD'nin Java tarzı / kural denetimi için daha güncel ürün olduğu yorumunu tekrarlamak isterim. FindBugs ile ilgili olarak, birçok ticari geliştirme grubu Coverity kullanıyor.

PMD, daha çok insanın bahsettiği şeydir. Checkstyle, insanların 4 yıl önce bahsettiği şeydi, ancak PMD'nin daha sürekli olarak sürdürüldüğüne ve diğer IDE'lerin / eklentilerin çalışmayı tercih ettiğine inanıyorum.

Checkstyle ve PMD kullanmaya yeni başladım. Benim için PMD'nin, System.gc (), Runtime.gc () gibi şeyler için özelleştirilmiş kurallar oluşturmak, XPath Sorgusunu yazabildiğiniz sürece daha kolaydır ki bu hiç de zor değildir. Ancak PMD bana sütun numarasını gösterme özelliğine sahip olduğunu göstermedi. Yani sütun limitlerini kontrol etmek gibi şeyler için. Checkstyle'ı kullanmak isteyebilirsiniz.

PMD, kontrol stilleri ile karşılaştırıldığında en iyi araçtır. Kontrol stilleri, PMD bunu yapmak için birçok özellik sunarken kodu analiz etme yeteneğine sahip olmayabilir! Ders Dışı PMD javadoc, yorumlar, girintiler vb. İçin kurallar yayınlamadı Ve bu arada bu kuralları uygulamayı planlıyorum ....... thanx