Statik analiz araçları için genellikle CPD, PMD , FindBugs ve Checkstyle kullanıyorum .
CPD, PMD "Kopyala / Yapıştır Detektörü" aracıdır. Ben fark etmeden ise küçük için PMD kullanıyordu "bulma çoğaltılmış kodu" bağlantısını üzerinde PMD web sayfası .
Bu araçların bazen "kullanıma hazır" kuralların ötesine genişletilebileceğini belirtmek isterim. Ve sadece onları yeniden yazabilmeniz için açık kaynak oldukları için değil. Bu araçlardan bazıları, genişletilmelerine izin veren uygulamalarla veya "kancalarla" birlikte gelir. Örneğin, PMD, yeni kurallar oluşturmanıza izin veren "tasarımcı" aracıyla birlikte gelir . Ayrıca, Checkstyle, önemli özelleştirmeye izin veren özelliklere sahip DescendantToken denetimine sahiptir.
Bu araçları Ant tabanlı bir yapıyla entegre ediyorum . Yorumlu yapılandırmamı görmek için bağlantıyı takip edebilirsiniz.
Yapıyla basit entegrasyona ek olarak, araçları birkaç başka yolla bir şekilde "entegre" olacak şekilde yapılandırmayı yararlı buluyorum. Yani, rapor oluşturma ve uyarı bastırma homojenliği. Bu tartışmaya şu yönleri eklemek istiyorum (muhtemelen "statik analiz" etiketi de olmalıdır): millet, "birleşik" bir çözüm oluşturmak için bu araçları nasıl yapılandırıyor? (Bu soruyu burada ayrıca sordum )
İlk olarak, uyarı raporları için çıktıyı her uyarının basit biçime sahip olması için dönüştürüyorum:
/absolute-path/filename:line-number:column-number: warning(tool-name): message
Buna genellikle "Emacs formatı" adı verilir, ancak Emacs kullanmasanız bile, raporları homojenleştirmek için makul bir formattır. Örneğin:
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.
Uyarı formatı dönüşümlerim Ant betiğim tarafından Ant filtre zincirleri ile yapılır .
Yaptığım ikinci "entegrasyon" uyarı bastırmak içindir. Varsayılan olarak her araç, yok saymak istediğiniz bir uyarıyı susturmak için kodunuza yerleştirebileceğiniz yorumları veya ek açıklamayı (veya her ikisini) destekler. Ancak bu çeşitli uyarı bastırma talepleri, biraz aptalca görünen tutarlı bir görünüme sahip değildir. Bir uyarıyı bastırdığınızda, bir uyarıyı bastırıyorsunuz, öyleyse neden her zaman " SuppressWarning" yazmıyorsunuz ?
Örneğin, PMD'nin varsayılan yapılandırması NOPMD, bir açıklamada " " dizesi bulunan kod satırlarında uyarı oluşturmayı bastırır . Ayrıca PMD, Java'nın @SuppressWarningsaçıklamasını destekler . PMD'yi PMD bastırmalarının benzer görünmesi için SuppressWarning(PMD.yerine " " içeren yorumları kullanacak şekilde yapılandırıyorum NOPMD. Yorum stili gizlemeyi kullanırken ihlal edilen belirli kuralı dolduruyorum:
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained
SuppressWarnings(PMD.Bir yorum için yalnızca " " kısmı önemlidir, ancak PMD'nin @SuppressWarningbireysel kural ihlallerini isme göre tanıyan ek açıklama desteğiyle tutarlıdır :
@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended
Benzer şekilde, Checkstyle yorum çiftleri arasında uyarı oluşumunu engeller (ek açıklama desteği sağlanmaz). Varsayılan olarak, yorum Checkstyle kapatıp üzerine dizeleri içermesi CHECKSTYLE:OFFve CHECKSTYLE:ONsırasıyla. Bu yapılandırmanın (Checkstyle'ın "SuppressionCommentFilter" ile) " BEGIN SuppressWarnings(CheckStyle." ve " END SuppressWarnings(CheckStyle." dizelerini kullanacak şekilde değiştirilmesi , kontrollerin daha çok PMD gibi görünmesini sağlar:
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)
Checkstyle yorum ile, özellikle çek ihlali ( HiddenField) olan her çek kendine "çünkü önemli BEGIN/END" yorum çifti.
FindBugs ayrıca bir @SuppressWarningsaçıklama ile uyarı oluşturmayı engellemeyi de destekler , bu nedenle diğer araçlarla belirli bir düzeyde tekdüzelik elde etmek için daha fazla yapılandırma gerekmez. Maalesef, Findbugs'ın özel bir @SuppressWarningsaçıklamayı desteklemesi gerekir çünkü yerleşik Java @SuppressWarningsaçıklama, SOURCEFindBugs'ın ihtiyaç duyduğu sınıf dosyasındaki açıklamayı tutacak kadar güçlü olmayan bir saklama politikasına sahiptir. Java'nın @SuppressWarningsek açıklamasıyla çakışmayı önlemek için FindBugs uyarı engellemelerini tam olarak nitelendiriyorum :
@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")
Bu teknikler, nesnelerin araçlar arasında makul ölçüde tutarlı görünmesini sağlar. Her bir uyarı bastırmanın " SuppressWarnings" dizesini içermesinin, bir kod tabanının tamamında tüm araçların tüm örneklerini bulmak için basit bir arama çalıştırmayı kolaylaştırdığını unutmayın.