Lint dan Format

Lint memeriksa kode tanpa menjalankannya, lalu melaporkan pelanggaran gaya, struktur, dan pola yang berisiko. Pada ekosistem Kotlin, dua alat lint yang paling umum adalah ktlint untuk gaya penulisan dan detekt untuk analisis statis, dan keduanya saling melengkapi dengan inspeksi bawaan IDE. Topik ini membahas peran masing-masing alat, bentuk pelanggaran ktlint beserta perbaikannya, konfigurasi detekt melalui berkas YAML, serta cara menyatukan ketiganya dalam kebiasaan kerja harian.

Dua alat dengan peran berbeda#

ktlint mengacu pada Kotlin Coding Conventions yang diterbitkan JetBrains, lalu memeriksa kesesuaian kode terhadap aturan tersebut. Pelanggaran yang paling sering ditangkapnya berkaitan dengan format, misalnya spasi yang kurang, urutan import yang acak, dan titik koma yang tidak perlu. Alat ini juga berperan sebagai formatter, karena sebagian besar pelanggaran dapat diperbaiki secara otomatis melalui opsi format.

detekt bergerak pada lapisan lain, yaitu analisis statis (static analysis) yang membaca struktur program. Aturannya menghitung kompleksitas, menandai fungsi yang terlalu panjang, memperingatkan blok catch yang kosong, dan mendeteksi pola lain yang sering disebut code smell. detekt tidak menyunting kode, melainkan melaporkan lokasi pelanggaran beserta jenis aturannya, sehingga keputusan perbaikan tetap di tangan pengembang.

Pelanggaran ktlint dan perbaikannya#

Contoh berikut memuat tiga pelanggaran yang lazim, yaitu import wildcard, import yang tidak terpakai, dan titik koma yang tidak perlu, ditambah spasi yang kurang pada deklarasi parameter. ktlint menandai semuanya dan kebanyakan dapat diperbaiki tanpa sentuhan manual.

// tidak-dijalankan
import kotlin.math.*
import java.io.File ;
import java.nio.file.Paths

fun bacaBaris(berkas:File):String {
    return File(berkas.path).readText() ;
}

// tidak-dijalankan
import java.io.File

fun bacaBaris(berkas: File): String {
    return File(berkas.path).readText()
}

Perbaikan di atas menghapus import kotlin.math.* dan java.nio.file.Paths karena tidak dipakai, melepas titik koma, dan menambah spasi pada daftar parameter. Dengan ukuran proyek yang nyata, perbaikan semacam ini memakan waktu bila dilakukan manual, padahal ktlint melakukannya dalam sekali eksekusi.

# tidak-dijalankan
# memeriksa seluruh berkas Kotlin pada direktori src, lalu melaporkan pelanggaran
ktlint "src/**/*.kt"
# memperbaiki pelanggaran yang mendukung perbaikan otomatis
ktlint --format "src/**/*.kt"

Perintah pertama hanya melaporkan pelanggaran beserta nomor barisnya, sedangkan perintah kedua menyunting berkasnya langsung. Karena perbaikan otomatis mengubah kode, kebiasaan yang aman adalah menjalankan format sebelum mengukur perubahan lain, sehingga diff pada kontrol versi berisi perbaikan gaya yang terpisah dari perubahan logika.

Konfigurasi detekt melalui berkas YAML#

detekt membaca konfigurasinya dari berkas YAML yang menetapkan aturan aktif dan ambang batasnya. Berkas berikut mengatur dua hal, yaitu batas maksimal pelanggaran yang ditoleransi dan panjang maksimal sebuah fungsi.

build:
  maxIssues: 0

complexity:
  LongMethod:
    threshold: 60
  LongParameterList:
    functionThreshold: 6

Nilai maxIssues: 0 berarti detekt gagal bila ada satu pelanggaran pun, pilihan yang lazim untuk proyek yang menegakkan aturannya secara ketat. Blok complexity mengatur kumpulan aturan kompleksitas, dengan fungsi yang melebihi 60 baris diberi tanda dan fungsi dengan lebih dari enam parameter mengikuti ambang yang sama pada kumpulan aturan itu. Kumpulan aturan lain yang tersedia di antaranya adalah naming untuk aturan penamaan, exceptions untuk penanganan error, performance untuk pola yang boros, dan potential-bugs untuk pola yang sering menghasilkan bug.

# tidak-dijalankan
# menjalankan detekt dengan konfigurasi khusus proyek
detekt --input src --config detekt.yml --report html:laporan/detekt.html

Opsi --input menentukan direktori yang diperiksa, --config menunjuk berkas konfigurasi di atas, dan --report menghasilkan laporan HTML yang memudahkan penelusuran temuan pada proyek besar.

Inspeksi IDE dan satu sumber kebenaran#

IntelliJ IDEA memuat inspeksi bawaan yang berjalan saat kode diketik, mulai dari gaya sampai potensi bug, dan perintah Inspect Code menjalankan seluruh pemeriksaan tersebut atas satu cakupan proyek. Inspeksi IDE bersifat seketi tetapi terikat pada lingkungan satu orang, sedangkan ktlint dan detekt dari baris perintah menghasilkan aturan yang sama di setiap komputer. Ketiganya bersifat saling melengkapi, bukan saling menggantikan.

Masalah yang sering muncul adalah berbedanya penilaian antaralat, misalnya IDE menerima kode yang ditolak detekt. Penyelesaiannya adalah menetapkan satu sumber kebenaran, yaitu berkas konfigurasi ktlint dan detekt yang tersimpan di dalam repositori dan dipatuhi oleh semua pemeriksa. Dengan konfigurasi yang sama di mana pun, temuan IDE, baris perintah, dan mesin pembangun otomatis tidak saling bertentangan.

Ringkasan#

• ktlint memeriksa kode terhadap Kotlin Coding Conventions dan memperbaiki sebagian besar pelanggarannya secara otomatis.
• detekt melakukan analisis statis dengan kumpulan aturan seperti complexity, naming, dan potential-bugs, dikonfigurasi melalui berkas YAML.
• Nilai maxIssues: 0 menjadikan setiap pelanggaran sebagai kegagalan, sehingga aturan proyek ditegakkan secara konsisten.
• Inspeksi IDE memberi masukan saat mengetik, sedangkan konfigurasi yang tersimpan di repositori menjadi sumber kebenaran bagi semua alat pemeriksa.

Referensi#

• ktlint — ktlint contributors — Dokumentasi resmi ktlint, mencakup aturan bawaan, pemakaian CLI, dan perbaikan otomatis.
• detekt — detekt contributors — Dokumentasi resmi detekt, mencakup kumpulan aturan dan berkas konfigurasi YAML.