Apakah masuk akal untuk menghitung kompleksitas siklomatik / garis rasio kode?

8

Secara umum, indeks rawatan bergantung pada banyak faktor. Misalnya, dalam Visual Studio, itu bergantung pada kompleksitas siklomatik, kedalaman warisan, penggabungan kelas dan garis kode; keempat nilai tersebut harus serendah mungkin.

Pada saat yang sama, saya belum pernah melihat, baik dalam alat metrik kode, maupun dalam buku, perbandingan antara hanya kompleksitas siklomatik (CC) dan baris kode (LC).

Apakah masuk akal untuk menghitung rasio seperti itu? Informasi apa yang diberikannya tentang kode? Dengan kata lain, apakah lebih baik mengurangi lebih banyak CC daripada LC untuk memiliki rasio yang lebih rendah?

Yang saya perhatikan adalah bahwa untuk proyek-proyek kecil, rasio CC / LC rendah (⅓ dan lebih rendah). Dengan kata lain, LC tinggi, dan CC rendah. Dalam proyek besar, CC / LC dalam banyak kasus lebih besar dari ½. Mengapa?

— Arseni Mourzenko
sumber

13

Satu-satunya metrik kualitas kode yang valid adalah WTFs / menit;)

1

Prediksi terakhir Anda (proyek kecil x besar) mungkin tergantung pada platform dan jumlah kode boilerplate yang harus ditulis seseorang untuk menjalankan proyek minimal. Menggunakan API Win32 mentah, jumlah boilerplate ke kode sebenarnya tinggi untuk proyek-proyek kecil, misalnya. Ini mengembang jumlah baris kode. Anda dapat memilih beberapa proyek open source acak dan melakukan sebar plot CC x LC. Mungkin Anda dapat menemukan sesuatu yang bermanfaat darinya.

— Vitor Py

Rasio yang Anda sarankan adalah IMO yang menarik tetapi saya ingin menyarankan untuk mengganti baris kode (LOC) dengan Function Points (FP) atau Use Case points (UCP) dan lihat apa yang Anda dapatkan.

— M.Sameer

4

Dari http://en.wikipedia.org/wiki/Cyclomatic_complexity

Les Hatton mengklaim baru-baru ini (Keynote di TAIC-PART 2008, Windsor, UK, September 2008) bahwa McCabe Cyclomatic Complexity memiliki kemampuan prediksi yang sama dengan baris kode. [11]

Rasio ini memiliki kemampuan prediksi yang sama seperti yang digunakan secara terpisah.

— S.Lott
sumber

1

Saya tidak setuju. Cyclomatic Complexity (CC) jelas berkorelasi dengan Logical Lines of Code (LLOC). Semakin besar proyek Anda, semakin tinggi kompleksitasnya. Ini jelas. Tetapi CC / LLOC tidak memiliki korelasi dengan ukuran proyek (saya telah melihat contoh nyata). Rasio ini tergantung pada tiga hal: bahasa dan kerangka kerja yang digunakan, kompleksitas fungsional proyek dan gaya kode. Jika dua elemen pertama tidak dapat diubah dengan mudah, yang ketiga dapat menjadi indikasi kualitas kode yang jelas.

— Alexandre Butynski

6

Ada metrik kompleksitas siklomatik per pernyataan sumber - ini disebut kepadatan kompleksitas siklomatik . Metrik ini dapat digunakan untuk memperkirakan waktu pemeliharaan dan upaya yang diperlukan untuk proyek perangkat lunak.

— Thomas Owens
sumber

3

Seperti disebutkan dalam balasan sebelumnya, pernyataan ini dalam jawaban yang diterima jelas salah.

Rasio ini memiliki kemampuan prediksi yang sama seperti yang digunakan secara terpisah.

Kepadatan CC telah ditemukan masuk akal oleh berbagai peneliti, meskipun tampaknya tidak mendapatkan popularitas yang signifikan di kalangan praktisi. Ada bukti dari dua cendekiawan terkenal di bidang metrik perangkat lunak bahwa rasio (kepadatan kompleksitas siklomatik = CC / KLOC) adalah prediktor yang jauh lebih baik dari produktivitas pemeliharaan daripada CC atau KLOC saja.

GK Gill dan CF Kemerer, "Kepadatan kompleksitas siklus dan produktivitas pemeliharaan perangkat lunak," dalam Transaksi IEEE pada Rekayasa Perangkat Lunak, vol. 17, tidak. 12, hlm. 1284-1288, Desember 1991. doi: 10.1109 / 32.106988

Ada banyak lainnya yang telah dibangun di atas karya ini untuk memperbaiki metrik berbasis kepadatan CC. Dua contoh:

T. Andersson, K. Enholm dan A. Törn. Panjang kerumitan ukuran perangkat lunak yang independen. Dalam M. Ross, CA Brebbia, C. Staples, dan J. Stapleton (eds.) Konferensi Internasional Kedua tentang Manajemen Kualitas Perangkat Lunak, Vol 1, Mengelola Sistem Kualitas, 1994.
JP Mittal, Pradeep Bhatia, dan Harish Mittal. 2009. Penilaian produktivitas pemeliharaan perangkat lunak menggunakan logika fuzzy. SIGSOFT Softw. Eng Catatan 34, 5 (Oktober 2009), 1-4. DOI = http://dx.doi.org/10.1145/1598732.1598739

— Nikos Houssos
sumber

Dan haruskah itu tinggi, rendah, dalam kisaran tertentu, atau ide samar "masuk akal" untuk kasus terbaik, sesuai dengan itu?

— Deduplicator

Artikel tersebut menyatakan bahwa dalam modul tertentu dari sistem yang diselidiki nilainya antara 0,10 dan 0,12. Saya telah mengamati dalam nilai-nilai aplikasi web produksi cukup rumit, memohon-untuk-refactoring antara 0,18-0,20. Saya menduga bahwa apa pun di sekitar 0,20 mungkin terlalu kompleks, sementara nilai yang lebih dekat ke 0,10 menunjukkan tingkat kerapatan kompleksitas yang cukup rendah - namun, lebih banyak data diperlukan untuk hasil yang lebih aman.

— Nikos Houssos

1

Maaf tapi saya tidak setuju dengan pernyataan ini:

Rasio ini memiliki kemampuan prediksi yang sama seperti yang digunakan secara terpisah.

Rasio jelas tidak sama dengan metrik individu. Berdasarkan data empiris, Hatton mengklaim bahwa CC sebanding dengan XLOC dengan rasio konstan sekitar 0,25 (lihat slide 17) untuk kumpulan data spesifiknya. Maka apakah XLOC Anda adalah 60 atau 400, rasio CC: XLOC Anda akan menjadi sekitar 0,25 (mengabaikan penyimpangan statistik pada angka yang lebih tinggi). Jadi rasionya tidak bisa diprediksi sama sekali.

— Brian Rowe
sumber

tentunya Anda lebih cenderung mendapat penyimpangan statistik dengan jumlah kecil

— jk.