Untuk alat analisis statis saya sering menggunakan CPD, PMD , FindBugs , dan Checkstyle .
CPD adalah alat PMD "Copy / Paste Detector". Saya menggunakan PMD untuk beberapa saat sebelum saya melihat link "Menemukan Kode yang Digandakan" di halaman web PMD .
Saya ingin menunjukkan bahwa alat-alat ini terkadang dapat diperluas melampaui seperangkat aturan "di luar kotak" mereka. Dan bukan hanya karena ini open source sehingga Anda dapat menulis ulang. Beberapa alat ini dilengkapi dengan aplikasi atau "pengait" yang memungkinkannya diperpanjang. Misalnya, PMD dilengkapi dengan alat "desainer" yang memungkinkan Anda membuat aturan baru. Selain itu, Checkstyle memiliki cek DescendantToken yang memiliki properti yang memungkinkan penyesuaian substansial.
Saya mengintegrasikan alat ini dengan build berbasis Ant . Anda dapat mengikuti tautan untuk melihat konfigurasi saya yang dikomentari.
Selain integrasi sederhana ke dalam build, saya merasa terbantu untuk mengonfigurasi alat agar agak "terintegrasi" dalam beberapa cara lain. Yakni, pembuatan laporan dan keseragaman penekanan peringatan. Saya ingin menambahkan aspek ini ke diskusi ini (yang mungkin juga memiliki tag "analisis-statis"): bagaimana orang mengonfigurasi alat ini untuk membuat solusi "terpadu"? (Saya telah menanyakan pertanyaan ini secara terpisah di sini )
Pertama, untuk laporan peringatan, saya mengubah output sehingga setiap peringatan memiliki format sederhana:
/absolute-path/filename:line-number:column-number: warning(tool-name): message
Ini sering disebut "format Emacs", tetapi meskipun Anda tidak menggunakan Emacs, ini adalah format yang masuk akal untuk menyeragamkan laporan. Sebagai contoh:
/project/src/com/example/Foo.java:425:9: warning(Checkstyle):Missing a Javadoc comment.
Transformasi format peringatan saya dilakukan oleh skrip Ant saya dengan rantai filter Ant .
"Integrasi" kedua yang saya lakukan adalah untuk menekan peringatan. Secara default, setiap alat mendukung komentar atau anotasi (atau keduanya) yang dapat Anda tempatkan di kode Anda untuk membungkam peringatan yang ingin Anda abaikan. Namun berbagai permintaan penekanan peringatan ini tidak memiliki tampilan yang konsisten yang tampaknya agak konyol. Saat Anda menekan sebuah peringatan, Anda menekan sebuah peringatan, jadi mengapa tidak selalu menulis " SuppressWarning?"
Misalnya, konfigurasi default PMD menekan pembuatan peringatan pada baris kode dengan string " NOPMD" dalam komentar. Selain itu, PMD mendukung @SuppressWarningsanotasi Java . Saya mengonfigurasi PMD untuk menggunakan komentar yang berisi " SuppressWarning(PMD." alih-alih NOPMDagar penekanan PMD terlihat sama. Saya mengisi aturan tertentu yang dilanggar saat menggunakan penekanan gaya komentar:
// SuppressWarnings(PMD.PreserveStackTrace) justification: (false positive) exceptions are chained
Hanya bagian " SuppressWarnings(PMD." yang signifikan untuk komentar, tetapi konsisten dengan dukungan PMD untuk @SuppressWarninganotasi yang mengenali pelanggaran aturan individu berdasarkan nama:
@SuppressWarnings("PMD.CompareObjectsWithEquals") // justification: identity comparision intended
Demikian pula, Checkstyle menekan pembuatan peringatan di antara pasangan komentar (tidak ada dukungan anotasi yang disediakan). Secara default, komentar untuk menonaktifkan dan mengaktifkan Checkstyle berisi string CHECKSTYLE:OFFdan CHECKSTYLE:ON, masing-masing. Mengubah konfigurasi ini (dengan "SuppressionCommentFilter" dari Checkstyle) untuk menggunakan string " BEGIN SuppressWarnings(CheckStyle." dan " END SuppressWarnings(CheckStyle." membuat kontrol lebih mirip PMD:
// BEGIN SuppressWarnings(Checkstyle.HiddenField) justification: "Effective Java," 2nd ed., Bloch, Item 2
// END SuppressWarnings(Checkstyle.HiddenField)
Dengan komentar Checkstyle, pelanggaran centang tertentu ( HiddenField) menjadi signifikan karena setiap tanda centang memiliki BEGIN/ENDpasangan komentar " " sendiri .
FindBugs juga mendukung penghentian pembuatan peringatan dengan @SuppressWarningsanotasi, jadi tidak diperlukan konfigurasi lebih lanjut untuk mencapai beberapa tingkat keseragaman dengan alat lain. Sayangnya, Findbugs harus mendukung @SuppressWarningsanotasi khusus karena anotasi Java @SuppressWarningsbawaan memiliki SOURCEkebijakan penyimpanan yang tidak cukup kuat untuk mempertahankan anotasi di file kelas tempat FindBugs membutuhkannya. Saya sepenuhnya memenuhi syarat penindasan peringatan FindBugs untuk menghindari bentrok dengan @SuppressWarningsanotasi Java :
@edu.umd.cs.findbugs.annotations.SuppressWarnings("UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR")
Teknik ini membuat segala sesuatunya terlihat cukup konsisten di seluruh alat. Perhatikan bahwa setiap penekanan peringatan berisi string " SuppressWarnings" memudahkan untuk menjalankan pencarian sederhana untuk menemukan semua contoh untuk semua alat di seluruh basis kode.