Pengantar CheckStyle

1. Ikhtisar

Checkstyle adalah alat sumber terbuka yang memeriksa kode terhadap sekumpulan aturan yang dapat dikonfigurasi.

Dalam tutorial ini, kita akan melihat bagaimana mengintegrasikan Checkstyle ke dalam proyek Java melalui Maven dan dengan menggunakan plugin IDE.

Plugin yang disebutkan di bagian bawah tidak bergantung satu sama lain dan dapat diintegrasikan secara individual dalam build atau IDE kami. Misalnya, plugin Maven tidak diperlukan di pom.xml kami untuk menjalankan validasi di Eclipse IDE kami.

2. Plugin Checkstyle Maven

2.1. Konfigurasi Maven

Untuk menambahkan Checkstyle ke proyek, kita perlu menambahkan plugin di bagian pelaporan pom.xml :

   org.apache.maven.plugins maven-checkstyle-plugin 3.0.0  checkstyle.xml    

Plugin ini dilengkapi dengan dua pemeriksaan standar, pemeriksaan gaya Sun, dan pemeriksaan gaya Google . Pemeriksaan default untuk sebuah proyek adalah sun_checks.xml.

Untuk menggunakan konfigurasi khusus kita, kita dapat menentukan file konfigurasi kita seperti yang ditunjukkan pada contoh di atas. Dengan menggunakan konfigurasi ini, sekarang plugin akan membaca konfigurasi kustom kita, bukan konfigurasi default yang disediakan.

Versi terbaru plugin dapat ditemukan di Maven Central.

2.2. Pembuatan Laporan

Sekarang plugin Maven kami telah dikonfigurasi, kami dapat membuat laporan untuk kode kami dengan menjalankan perintah situs mvn . Setelah build selesai, laporan tersedia di folder target / situs dengan nama checkstyle.html.

Ada tiga bagian utama dalam laporan Checkstyle:

File: Bagian laporan ini memberi kami daftar file tempat pelanggaran telah terjadi . Ini juga menunjukkan kepada kita jumlah pelanggaran terhadap tingkat keparahannya. Berikut tampilan bagian file di laporan:

Aturan: Bagian laporan ini memberi kami gambaran umum tentang aturan yang digunakan untuk memeriksa pelanggaran . Ini menunjukkan kategori aturan, jumlah pelanggaran dan tingkat keparahan pelanggaran tersebut. Berikut adalah contoh laporan yang menunjukkan bagian aturan:

Detail: Terakhir, bagian detail laporan memberi kami detail pelanggaran yang telah terjadi . Detail yang diberikan ada di tingkat nomor baris. Berikut adalah contoh detail bagian laporan:

2.3. Bangun Integrasi

Jika ada kebutuhan untuk melakukan pemeriksaan ketat pada gaya pengkodean, kita dapat mengkonfigurasi plugin sedemikian rupa sehingga build gagal ketika kode tidak sesuai dengan standar.

Kami melakukan ini dengan menambahkan tujuan eksekusi ke definisi plugin kami:

 org.apache.maven.plugins maven-checkstyle-plugin ${checkstyle-maven-plugin.version}  checkstyle.xml     check    

The configLocation mendefinisikan atribut yang file konfigurasi untuk merujuk untuk validasi.

Dalam kasus kami, file konfigurasinya adalah checkstyle.xml. Tujuan pemeriksaan disebutkan pada bagian eksekusi meminta plugin untuk berjalan dalam memverifikasi fase membangun dan pasukan kegagalan membangun ketika pelanggaran standar pengkodean terjadi.

Sekarang, jika kita menjalankan perintah mvn clean install , itu akan memindai file dari pelanggaran dan build akan gagal jika ditemukan pelanggaran.

Kita juga dapat menjalankan hanya tujuan pemeriksaan plugin menggunakan mvn checkstyle: check, tanpa mengkonfigurasi tujuan eksekusi. Menjalankan langkah ini juga akan mengakibatkan kegagalan build jika ada kesalahan validasi.

3. Plugin Eclipse

3.1. Konfigurasi

Sama seperti integrasi Maven, Eclipse memungkinkan kita menggunakan konfigurasi kustom kita.

Untuk mengimpor konfigurasi kita, buka Window -> Preferences -> Checkstyle. Di bagian Konfigurasi Pemeriksaan Global , klik Baru.

Ini akan membuka dialog yang akan memberi kita opsi untuk menentukan file konfigurasi kustom kita.

3.2. Laporan Penjelajahan

Sekarang plugin kami telah dikonfigurasi, kami dapat menggunakannya untuk menganalisis kode kami.

Untuk memeriksa gaya pengkodean suatu proyek, klik kanan proyek di Eclipse Project Explorer dan pilih CheckStyle -> Periksa Kode dengan Checkstyle.

Plugin akan memberi kami umpan balik tentang kode Java kami di dalam Eclipse, editor teks. Ini juga akan menghasilkan laporan pelanggaran untuk proyek yang tersedia sebagai tampilan di Eclipse.

Untuk melihat laporan pelanggaran, pergi ke Window -> Show View -> Other , dan cari Checkstyle. Pilihan untuk Pelanggaran dan Pelanggaran Bagan harus ditampilkan.

Memilih salah satu opsi akan memberi kami representasi pelanggaran yang dikelompokkan berdasarkan jenis. Berikut diagram lingkaran pelanggaran untuk proyek contoh:

Mengeklik bagian diagram lingkaran akan membawa kita ke daftar pelanggaran aktual dalam kode.

Sebagai alternatif, kita dapat membuka tampilan Masalah di Eclipse IDE dan memeriksa masalah yang dilaporkan oleh plugin.

Berikut adalah contoh Tampilan Masalah dari Eclipse IDE:

Mengklik salah satu peringatan akan membawa kami ke kode tempat pelanggaran telah terjadi.

4. Plugin IntelliJ IDEA

4.1. Konfigurasi

Seperti Eclipse, IntelliJ IDEA juga memungkinkan kami menggunakan konfigurasi khusus kami sendiri dengan sebuah proyek.

Di IDE buka Pengaturan dan cari Checkstyle. Sebuah jendela ditampilkan yang memiliki opsi untuk memilih cek kami. Klik pada tombol + dan sebuah jendela akan terbuka yang akan membiarkan kami menentukan lokasi file yang akan digunakan.

Sekarang, kami memilih file XML konfigurasi dan klik Next. Ini akan membuka jendela sebelumnya dan menampilkan opsi konfigurasi kustom yang baru kami tambahkan. Kami memilih konfigurasi baru dan klik OK untuk mulai menggunakannya dalam proyek kami.

4.2. Laporan Penjelajahan

Sekarang plugin kita telah dikonfigurasi, mari kita gunakan untuk memeriksa pelanggaran. Untuk memeriksa pelanggaran proyek tertentu, buka Analisis -> Periksa Kode.

Hasil Inspeksi akan memberi kita pandangan tentang pelanggaran di bawah bagian Checkstyle. Berikut adalah contoh laporannya:

Mengklik pelanggaran akan membawa kami ke baris yang tepat di file tempat pelanggaran terjadi.

5. Konfigurasi Checkstyle Kustom

Di bagian pembuatan laporan Maven (Bagian 2.2), kami menggunakan file konfigurasi kustom untuk melakukan pemeriksaan standar pengkodean kami sendiri.

Kami memiliki cara untuk membuat file XML konfigurasi kustom kami sendiri jika kami tidak ingin menggunakan paket pemeriksaan Google atau Sun.

Berikut adalah file konfigurasi khusus yang digunakan untuk pemeriksaan di atas:

5.1. DOCTYPE Definisi

Baris pertama dari definisi DOCTYPE ie adalah bagian penting dari file dan memberitahukan dari mana mendownload DTD sehingga konfigurasinya dapat dipahami oleh sistem.

Jika kami tidak menyertakan definisi ini dalam file konfigurasi kami tidak akan menjadi file konfigurasi yang valid.

5.2. Modul

File konfigurasi terutama terdiri dari Modul. Sebuah modul memiliki nama atribut yang mewakili apa yang dilakukan modul tersebut. Nilai atribut name sesuai dengan kelas dalam kode plugin yang dijalankan saat plugin dijalankan.

Mari belajar tentang berbagai modul yang ada dalam konfigurasi di atas.

5.3. Rincian Modul

  • Pemeriksa: Modul disusun dalam pohon yang memiliki modul Pemeriksa di root. Modul ini mendefinisikan properti yang diwarisi oleh semua modul konfigurasi lainnya.
  • TreeWalker: Modul ini memeriksa file sumber Java individu dan mendefinisikan properti yang berlaku untuk memeriksa file tersebut.
  • HindariStarImport: Modul ini menetapkan standar untuk tidak menggunakan impor Star dalam kode Java kami. Ia juga memiliki properti yang meminta plugin untuk melaporkan tingkat keparahan masalah seperti peringatan. Jadi, setiap kali pelanggaran seperti itu ditemukan dalam kode, peringatan akan ditandai untuk pelanggaran tersebut.

Untuk membaca lebih lanjut tentang konfigurasi khusus, ikuti tautan ini.

6. Analisis Laporan untuk Proyek Spring-Rest

Di bagian ini, kami akan menjelaskan analisis yang dilakukan oleh Checkstyle, menggunakan konfigurasi kustom yang dibuat di bagian 5 di atas, pada proyek spring-rest yang tersedia di GitHub sebagai contoh.

6.1. Pembuatan Laporan Pelanggaran

Kami telah mengimpor konfigurasi ke Eclipse IDE dan berikut adalah laporan pelanggaran yang dibuat untuk proyek tersebut:

Peringatan yang dilaporkan di sini mengatakan bahwa impor karakter pengganti harus dihindari dalam kode. Kami memiliki dua file yang tidak sesuai dengan standar ini. Saat kita mengklik peringatan itu membawa kita ke file Java yang memiliki pelanggaran.

Berikut adalah cara file HeavyResourceController.java menampilkan peringatan yang dilaporkan:

6.2. Resolusi Masalah

Menggunakan impor Star bukanlah praktik yang baik secara umum karena dapat menimbulkan konflik ketika dua atau lebih paket berisi kelas yang sama.

Sebagai contoh, perhatikan kelas List, yang merupakan tersedia dalam paket java.util dan java.awt keduanya. Jika kita menggunakan kedua import java.util . * Dan java.awt. * Compiler kita akan gagal mengkompilasi kode, karena List tersedia di kedua paket.

Untuk mengatasi masalah yang disebutkan di atas, kami mengatur impor di kedua file dan menyimpannya. Sekarang ketika kami menjalankan plugin lagi kami tidak melihat pelanggaran dan kode kami sekarang mengikuti standar yang ditetapkan dalam konfigurasi kustom kami.

7. Kesimpulan

Pada artikel ini, kami telah membahas dasar-dasar untuk mengintegrasikan Checkstyle dalam proyek Java kami.

Kami telah mempelajari bahwa ini adalah alat sederhana namun kuat yang digunakan untuk memastikan bahwa pengembang mematuhi standar pengkodean yang ditetapkan oleh organisasi.

Kode sampel yang kami gunakan untuk analisis statis tersedia di GitHub.