Apakah jumlah rata-rata bug per lok sama untuk berbagai bahasa pemrograman? [Tutup]

Saya telah diberitahu bahwa jumlah rata-rata bug / cacat per baris kode adalah "konstan" untuk berbagai bahasa pemrograman. 10 KLOC dari Ruby akan memiliki jumlah bug yang sama dengan 10 KLOC dari c ++. Argumen ini biasanya digunakan untuk mempromosikan penggunaan bahasa ekspresif (pikirkan python / ruby ​​over c ++ / assembly) karena jumlah baris untuk menggambarkan fungsi yang sama akan lebih kecil.

Adakah yang tahu dari mana klaim ini berasal? Apakah bahasa tingkat tinggi menyebabkan lebih sedikit bug?

Berlawanan dengan intuisi, jumlah kesalahan per 1000 baris tampaknya relatif konstan, terlepas dari bahasa tertentu yang terlibat. Steve McConnell , penulis Code Complete dan Estimasi Perangkat Lunak: Demystifying the Black Art membahas masalah ini secara mendetail.

Saya tidak punya salinan saya siap untuk tangan - mereka duduk di rak buku saya di tempat kerja - tetapi Google cepat menemukan kutipan yang relevan:

Rata-Rata Industri: "sekitar 15 - 50 kesalahan per 1000 baris kode yang dikirimkan."
(Steve) lebih lanjut mengatakan ini biasanya mewakili kode yang memiliki beberapa tingkat pemrograman terstruktur di belakangnya, tetapi mungkin termasuk campuran teknik pengkodean.

Dikutip dari Code Complete , ditemukan di sini: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

Jika ingatanku benar, Steve membahas hal ini dengan seksama, menunjukkan bahwa angka-angkanya konstan di semua bahasa (C, C ++, Java, Assembly, dan sebagainya) dan meskipun ada kesulitan (seperti mendefinisikan apa yang dimaksud dengan "baris kode").

Yang paling penting dia memiliki banyak kutipan untuk sumbernya - dia tidak menawarkan pendapat yang tidak berdasar, tetapi memiliki referensi untuk mendukungnya.

Kelihatannya bermuara pada hal ini: Jumlah rata-rata cacat per kloc tampaknya lebih merupakan fakta bahwa pengembang adalah manusia yang bisa keliru daripada kelebihan atau kekurangan khusus dari bahasa atau platform tertentu.

(Selain itu: Jika Anda belum memiliki Kode Lengkap, beli sendiri salinannya dan bacalah dengan seksama - itu sepadan dengan investasi.)

Pembaruan : Ada faktor lain yang berperan dengan beberapa jawaban di sini - statistik skala besar berguna untuk membuat prediksi umum tetapi tidak untuk yang spesifik. Pertimbangkan, tabel kematian populasi dapat memprediksi tentang berapa banyak orang yang akan terbunuh dalam kecelakaan lalu lintas tahun ini tetapi tidak dapat memberi tahu Anda orang mana yang akan mati. Demikian pula, statistik industri yang menunjukkan jumlah cacat per kloc yang relatif konstan tidak dapat digunakan untuk memprediksi seberapa baik - atau seberapa buruk - kinerja pengembang tertentu atau apa yang akan terjadi pada proyek tertentu.

Klaim itu - paling-paling - naif.

SLOC bukanlah metrik yang andal untuk apa pun yang berguna, kecuali mungkin membandingkan ukuran dua atau lebih proyek. Selain itu ada dua jenis SLOC, LOC fisik dan LOC logis, dan yang mungkin berbeda secara signifikan. Pertimbangkan contoh ini, dari Wikipedia :

for (i = 0; i < 100; i += 1) printf("hello"); 

Di sini kita memiliki satu LOC fisik, tetapi dua yang logis ( fordan printfpernyataan). Tetapi tentu saja kita dapat menulis contoh sebagai:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

Yang akan memberi kita dua LOC fisik dan dua logis. Saya pikir sudah jelas bahwa setiap pengukuran "bug per loc" yang akan tergantung pada LOC fisik akan ternoda oleh gaya pemrograman, sehingga pengukuran kami sebagian besar tidak berguna.

Sebaliknya, jika kita menggunakan LOC logis maka pengukuran kita akan sangat bergantung pada keanehan sintaksis bahasa tersebut. Meskipun metrik yang dihasilkan mungkin sedikit berguna ketika membandingkan proyek yang ditulis dalam bahasa yang sama, itu akan cukup berguna untuk proyek yang ditulis dalam bahasa yang berbeda.

Salah satu sumber yang mungkin untuk klaim ini adalah Kegagalan dan kekeliruan Perangkat Lunak Les Hatton :

Kita dapat menyimpulkan bahwa pilihan bahasa pemrograman paling lemah terkait dengan keandalan.

Kemudian, makalah ini menyebutkan kepadatan cacat yang sama untuk C dan C ++:

Dalam studi terbaru yang membandingkan dua sistem serupa dengan ukuran yang sama, (masing-masing sekitar 50.000 baris), satu dalam C dan satu dalam objek yang dirancang C ++, kepadatan cacat yang dihasilkan ditunjukkan sekitar sama pada 2,4 dan 2,9 per 1000 garis masing-masing.

Ini, bagaimanapun, tidak berarti bahwa "bug per LOC" adalah konstan di seluruh bahasa pemrograman, atau itu akan menjadi signifikan jika itu.

Pengamatan ini sangat tua, dan berasal dari sumber yang sangat terhormat, yaitu Fred Brooks dalam bukunya "The Mythical Man Month". Dia adalah manajer puncak di IBM, dan mengelola banyak proyek pemrograman termasuk sistem operasi mil / of-line OS / 360. Bahkan dia melaporkan bahwa jumlah bug dalam suatu program tidak sebanding dengan panjang kode, tetapi kuadratik ! Menurut penelitiannya, jumlah bug sebanding dengan panjang program dengan kekuatan 1.5. Dengan kata lain, sebuah program yang sepuluh kali lebih lama memiliki 30 kali lebih banyak bug. Dan dia melaporkan bahwa ini berlaku untuk semua bahasa pemrograman, dan level bahasa pemrograman.

Saya tidak menemukan Bug per LOC konstan untuk bahasa tertentu. Bug per LOC tampak seperti metrik yang digunakan beberapa Manajer untuk menentukan kualitas pengembang ketika datang untuk meninjau waktu.

Sekarang di luar itu, beberapa bahasa lebih rentan terhadap kesalahan atau cacat daripada yang lain. Biasanya, tetapi tidak selalu, ini adalah bahasa tingkat yang lebih rendah dari yang lebih tinggi. Misalnya pengkodean dalam C versus C # (atau Java.) Saya katakan biasanya karena kenyataan itu dan inti dari jawaban yang Anda cari turun ke kualitas pengembang dan praktik pengkodean di tempat. Saya telah melihat pengembang C yang sangat baik dengan kualitas kode yang jauh lebih tinggi dan jumlah cacat yang lebih rendah daripada pengembang Java / C # rata-rata. Ini adalah salah satu item yang memisahkan pengembang senior dari pengembang junior. Bukan berapa banyak LOC yang mereka tulis dalam kerangka waktu tertentu, tetapi kualitas kode yang ditulis terlepas dari bahasa, LOC, atau kerangka waktu.

Satu-satunya jawaban yang dapat saya berikan yang mungkin berhubungan adalah bahwa semakin banyak LOC, semakin besar kemungkinan ada cacat dan semakin banyak cacat yang ada.

Bug Per Baris Kode

Bug / LOC hanya relatif terhadap seorang individu. Untuk bisnis yang menerapkan alat pelacak bug yang menautkan dengan repositori kode sumber mereka. Mungkin bagi seorang manajer untuk mengatur masalah oleh pengembang, diurutkan berdasarkan masalah masa lalu dan perubahan kode.

Bug Relatif Terhadap Pekerjaan Anda

Pengembang perangkat lunak senior, yang sangat berpengalaman, sangat terampil, sangat cerdas dan mampu mengambil pekerjaan mandiri jauh lebih mungkin untuk memiliki lebih banyak bug yang masuk dalam sistem pelacakan, kemudian pengembang junior dengan sedikit pengalaman.

Bagaimana mungkin?

Pengembang senior sering terlibat dalam tugas pengembangan risiko yang lebih tinggi. Refactoring kode dan membangun sistem baru sebagai contoh. Pengembang junior sering ditugaskan untuk memperbaiki masalah yang diketahui yang tidak sepadan dengan waktu pengembang senior.

Oleh karena itu, dengan penugasan tugas, seorang junior tidak memperkenalkan bug tetapi memperbaikinya, dan seorang pengembang senior diizinkan mengambil risiko memperkenalkannya, karena manfaat dari apa yang mereka coba arsipkan lebih penting daripada masalah kecil yang diangkat menyelesaikan menyelesaikan masalah tersebut. tugas.

Sintaks Bahasa Penting

Argumen bahwa suatu bahasa memperkenalkan lebih sedikit bug, karena dapat mencapai lebih banyak dalam lebih sedikit baris kode adalah mitos yang lengkap. Bahasa yang sangat terstruktur seperti C ++ / C # / Java memaksa pengembang untuk secara jelas mengungkapkan secara tertulis apa yang harus menjadi instruksi yang diinginkan, sedangkan bahasa seperti Python / PHP sangat tidak terstruktur. Bahasa-bahasa itu memungkinkan untuk ekspresi tertulis yang tidak hanya akan membingungkan pengembang, tetapi juga pengurai bahasa.

Compiler Mengurangi Bug

Berapa banyak bug di Python / PHP yang berhasil masuk ke server produksi, karena tidak ada kompiler yang memperingatkan pengembang bahwa ada sesuatu yang salah. Ketika Anda mengukur bug per LOC adalah sebelum atau setelah kompiler memproses kode sumber?

Pembaruan 2019:

Kompiler tidak membuat perbedaan pada sifat atau jumlah bug. Bug murni relatif terhadap orang yang menulis kode sumber, dan bug itu sendiri bisa sangat subyektif.

FWIW, dalam pengalaman saya

1. Ada dua jenis bug: a) di mana program tidak memenuhi harapan, dan b) di mana program tidak dapat memenuhi harapan yang masuk akal, karena crash / hang / tidak mau dikompilasi.

2. Terlepas dari bahasa, bug tipe (b) disebabkan oleh redundansi dalam struktur data / kelas, di mana mengubah sesuatu di satu bagian dari struktur data menempatkan struktur dalam keadaan tidak konsisten / rusak sampai satu atau lebih perubahan yang sesuai dibuat di bagian lain . Berkontribusi pada hal ini adalah redundansi kode sumber, di mana pengeditan pada satu baris kode membuat kode salah sampai satu atau lebih perubahan dibuat di bagian lain. Kedua jenis redundansi ini berkaitan erat, tentu saja, dan karena programmer bukan orang super, mereka terganggu, melupakan hal-hal, dan membuat kesalahan, dengan demikian memasukkan bug.

Hal-hal ini (sekali lagi, dalam pengalaman saya) sebenarnya bukan fungsi dari bahasa, tetapi dari keterampilan / kematangan programmer. Program yang jauh lebih sedikit rawan bug juga cenderung jauh lebih kecil, dalam hal LOC, untuk serangkaian fungsi yang diberikan.

Saya telah melihat sistem di mana beberapa orang menulis program, sementara yang lain menulis direktori, dan yang pertama cenderung "hanya bekerja" dibandingkan dengan yang terakhir.

Saya akan berharap bahwa faktor kunci dalam pengkodean kesalahan berkaitan dengan apa yang saya sebut "celah semantik" antara jenis definisi solusi tertentu dan kode untuk menyelesaikannya - di mana ini adalah kesalahan reformulasi yang dekat akan lebih jelas, di mana kode tersebut sangat berbeda, banyak kesalahan bisa diharapkan. Paradigma bahasa tertentu sangat cocok dengan domain masalah tertentu - spreadsheet sangat sesuai dengan perhitungan bisnis sehari-hari, sehingga sangat sedikit "kode" dan "kode" yang sangat dekat dengan domain masalah. Kode yang diharapkan sangat ringkas (KLOC kecil) dan beberapa kesalahan. Sebaliknya menggunakan assembler akan membutuhkan banyak KLOC dan cenderung menghasilkan banyak kesalahan.

Alih-alih berbicara tentang baris kode - yang memang metrik yang tidak berguna - saya ingin membahas bagian dari pertanyaan Anda ini:

Apakah bahasa tingkat tinggi menyebabkan lebih sedikit bug?

Ini berbeda dari bug / LOC, karena bahasa tingkat yang lebih tinggi berbuat lebih banyak dengan lebih sedikit kode. Menerapkan beberapa persyaratan fitur mungkin membutuhkan 500 baris LISP vs 15000 baris x86.

Jadi, bahkan jika bug / LOC konstan di antara semua bahasa, bahasa tingkat yang lebih tinggi masih akan menghasilkan lebih sedikit bug.