Saya mendengar tentang analisis Kode Visual Studio tetapi tidak pernah menggunakannya. Saya telah membaca MSDN , tetapi masih belum memahami penggunaan analisis Kode yang sebenarnya.
Bukankah itu sama dengan StyleCop?
Di suatu tempat, FxCop juga disebutkan. Apa perbedaannya dengan analisis Kode?
Apakah saya perlu menggunakan analisis Kode untuk setiap proyek? Apakah ulasan kode yang dilakukan oleh kolega saya tidak cukup?
Jawaban:
Analisis kode (sebelumnya FxCop) adalah alat analisis statis yang mencari pola umum yang dapat menunjukkan bahwa ada sesuatu yang salah dalam kode sumber. Misalnya, jika instance kelas yang mengimplementasikannya IDisposabletidak dibuang dengan benar, analisis kode akan memancarkan peringatan:
private void DoSomething()
{
var connection = new SqlConnection(...);
this.ChangeSomeData(connection);
}Ini adalah implementasi yang benar dari potongan kode sebelumnya:
private void DoSomething()
{
using (var connection = new SqlConnection(...))
{
this.ChangeSomeData(connection);
}
}Seperti halnya alat analisis statis, analisis Kode dimaksudkan untuk menemukan pola yang rumit (atau hanya membosankan) untuk menemukan secara manual. Misalnya, dalam contoh sebelumnya, mungkin cukup membosankan bagi pengembang untuk memeriksa apakah ada kelas yang ia gunakan mengimplementasikan IDisposable(atau mengingat semua kelas .NET Framework yang mengimplementasikannya).
Meskipun tunduk pada positif palsu, seperti halnya alat analisis statis, biasanya bermanfaat untuk menargetkan nol peringatan untuk kode bisnis-kritis tanpa menggunakan penindasan . Dalam Visual Studio, analisis kode dapat dikonfigurasi untuk dijalankan pada waktu kompilasi; jika pengaturan proyek juga menentukan bahwa peringatan harus diperlakukan sebagai kesalahan, pelanggaran aturan analisis Kode tidak akan tetap diperhatikan.
Karena analisis statis dapat memakan waktu untuk proyek-proyek menengah atau besar, sering kali ide yang baik untuk memindahkannya dari mesin pengembang ke server build TFS. Meskipun menjalankan analisis Kode selama pra-komit bukanlah ide yang baik (tidak seperti StyleCop), itu masih dapat berjalan saat dibangun dan gagal jika peringatan ditemukan.
Untuk kode non-bisnis-kritis, analisis kode dapat dijalankan secara manual dari Visual Studio atau baris perintah. Pemeriksaan dan peringatan dapat dilakukan dengan baik di properti proyek agar sesuai dengan kebutuhan Anda. Misalnya, peringatan globalisasi dapat dimatikan jika proyek Anda tidak dimaksudkan untuk dilokalisasi.
Seperti halnya StyleCop, sangat penting untuk memutuskan apakah proyek akan menargetkan nol peringatan dari analisis Kode dari awal proyek. Memperkenalkannya dalam proyek yang ada mungkin terlalu menyakitkan.
Perhatikan bahwa analisis kode tidak sama dengan StyleCop . Perbedaan pertama adalah bahwa analisis Kode bekerja dengan rakitan yang dikompilasi, sementara StyleCop bekerja dengan sumber itu sendiri. Perbedaan kedua (dan paling penting) adalah bahwa analisis Kode mencari patters yang mungkin mengindikasikan bug, sementara StyleCop hanya menegakkan aturan gaya — konvensi sederhana yang digunakan oleh tim Anda.
Analisis kode juga sangat berguna bagi pemula yang tidak tahu bahasa dengan sangat baik , karena sering dapat menyebabkan "Aha!" momen. Misalnya, CA2105: Bidang array tidak boleh dibaca hanya dapat menyebabkan seseorang menemukan bahwa meskipun array ditandai sebagai read-only, itu tidak membuatnya tidak berubah, karena tidak ada yang melarang untuk mengubah elemen dalam array. StyleCop tidak mengarah pada penemuan: tidak ada yang menarik untuk mengetahui bahwa bidang dimulai dengan huruf kecil atau bahwa panggilan lokal harus diawali dengan this.
Bahkan jika beberapa aturan diberlakukan oleh kedua analisis Kode dan StyleCop (seperti CA1707: Pengidentifikasi tidak boleh berisi garis bawah vs SA1310: Nama bidang tidak boleh mengandung garis bawah ), kedua alat tersebut saling melengkapi dan sering digunakan berdampingan.
Kehadiran ulasan kode bukan alasan untuk menghindari analisis Kode. Analisis Kode dan StyleCop sangat baik dalam menemukan berbagai hal secara otomatis sebelum peninjauan kode. Tidak ada yang lebih buruk daripada menghabiskan ulasan kode yang menunjukkan masalah gaya atau pola bermasalah yang bisa ditemukan secara otomatis. Simpan ulasan kode untuk hal-hal menarik.
Aspek lain adalah bahwa peninjau manusia tidak selalu pandai menemukan masalah yang ditemukan oleh analisis Kode. Sebagai contoh, sebuah instance dari implementasi kelas IDisposabledapat dibuat di satu lokasi, dan kemudian dibuang di lokasi yang berbeda. Diperlukan beberapa waktu bagi pengulas untuk menemukannya, sementara itu hanya membutuhkan beberapa milidetik untuk alat analisis statis untuk menemukannya.