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


45

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?


11
Tampaknya tidak masuk akal mengingat bahwa beberapa bahasa mendorong gaya yang mengemas lebih banyak pernyataan menjadi satu baris daripada yang lainnya.
Caleb

10
Bug / LOC adalah metrik yang sangat salah untuk semuanya. Itu tergantung pada bahasa, tetapi lebih tergantung pada programmer, menulisnya. Jadi mengambil rata-rata untuk bahasa tidak masuk akal, karena fluktuasi besar berada di variabel lain. Ini hanya IMO, ofc.
K.Steff

3
Saya dapat memberitahu Anda bahwa jumlah bug / baris yang saya tulis di Perl akan jauh lebih besar daripada jumlah yang saya tulis di C. Seorang teman saya adalah penyihir Perl, dan baginya bug / baris jauh lebih besar di C daripada di Perl. Sulit untuk melihat bagaimana metrik ini mungkin berguna.
Caleb

4
Apakah Anda benar-benar berpikir bahwa {1≥⍴⍵:⍵⋄e←⍵[?⍴⍵]⋄ (∇(⍵<e)/⍵) , ((⍵=e)/⍵) , ∇(⍵>e)/⍵}kemungkinan besar mengandung kesalahan int pivot = arr.Count / 2;?
svick

2
Saya baru saja menemukan pertanyaan ini. Saya belum memiliki foggiest mengapa ditutup; ini adalah pertanyaan yang sempurna untuk situs ini. Untuk proyek besar, bug per KLOC bukanlah ukuran seberapa baik programmer. Ini adalah ukuran seberapa baik organisasi dan prosesnya.
David Hammen

Jawaban:


43

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.


4
Tidak memiliki salinan Estimasi Perangkat Lunak, tetapi dalam Kode Lengkap, McConnel mengutip laporan Capers Jones "Kualitas Program dan Produktivitas Programmer" 1977 sebagai sumber daftar kesalahan per LOC per ukuran proyek. Poin yang coba dibuat McConnel adalah bahwa kesalahan meningkat secara dramatis seiring dengan meningkatnya ukuran proyek, dan mencatat bahwa data hanya merupakan "snapsot industri" dan bahwa "jumlahnya mungkin sedikit mirip dengan yang ada pada proyek yang telah Anda kerjakan ". Saya tidak benar-benar melihat sesuatu di sana yang ada hubungannya dengan pertanyaan ini.
Roc Martí

Edisi Lengkap Kode manakah yang Anda miliki di @ RocMartí? Saya tahu bahwa edisi kedua adalah pembaruan besar. Harus menggali dan melihat apa yang dikatakannya ketika saya mulai bekerja Senin.
Bevan

Saya pikir hasil edit Anda ( Pembaruan:) adalah inti dari masalahnya. Atau, seperti yang dikatakan Mark Twain, ada tiga macam kebohongan: Kebohongan, Kebohongan Sial, dan Statistik.
GalacticCowboy

1
@ RocMartí "kesalahan meningkat secara dramatis ketika ukuran proyek meningkat" Apakah dia juga menunjukkan bahwa air basah? Tentu saja ada kesalahan ketika segalanya menjadi lebih rumit. Karena setiap perubahan baru harus diingat setiap bagian yang mungkin dapat dipengaruhi. Yang tumbuh seiring proyek tumbuh.
Parthian Shot

3
Kutipan salah atau kedaluwarsa. Dalam edisi kedua, ada di halaman 521: "Pengalaman rata-rata industri adalah sekitar 1 - 25 kesalahan per 1000 baris kode untuk perangkat lunak yang dikirim. Perangkat lunak ini biasanya telah dikembangkan dengan menggunakan teknik campur aduk."
Aryeh Leib Taurog

18

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.


Jika Anda menganggap bahwa bug / pernyataan adalah konstan maka ada perbedaan untuk bahasa. Contoh C umumnya memiliki bug di argumen for () dan printf (). Jika Anda harus kode fungsi printf keluar penuh Anda akan memiliki lebih banyak bug secara proporsional dan jika Anda memiliki bahasa tingkat yang lebih tinggi dengan satu printRepeat panggilan tunggal () panggilan akan ada lebih sedikit peluang untuk mendapatkannya salah.
Martin Beckett

2
Rangkuman: bug per pernyataan / titik fungsi adalah konstan, bahasa tingkat rendah memiliki lebih banyak kode yang ditulis oleh programmer yang keliru, bahasa tingkat tinggi yang Anda ketik lebih sedikit - karena itu lebih sedikit bug. Meskipun bug tipe desain yang benar-benar salah mungkin sama!
Martin Beckett

2
Apalagi apa yang merupakan "satu bug" sangat subjektif, dan bahwa bug sangat berbeda dalam tingkat keparahan, dampak, dan pentingnya.
tdammers

@tdammers Dan kepentingan itu bisa negatif. Kami memiliki beberapa bug yang digunakan klien untuk / mengharapkan / inginkan, jadi kami tidak dapat memperbaikinya ...
Izkata

@Izkata: tergantung pada definisi Anda tentang bug ...
tdammers

12

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.


6

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.


Pertanyaan saya adalah tentang jumlah rata-rata cacat per baris kode yang tidak tergantung pada bahasa.
Kristian

4
@Kristian tidak ada nomor seperti itu. Itu berubah per orang relatif terhadap pekerjaan dan keahlian pengembang dan bahasa yang mereka kodekan. Saya tidak berpikir ada rata-rata universal.
Akira71

1
@ Akira71 "tidak ada nomor seperti itu" Ya, tentu saja. Tetapi ada distribusi probabilitas, dari mana Anda dapat mengekstraksi angka. Juga tidak ada angka berapa inci curah hujan yang turun setiap tahun di hutan hujan Amazon, tetapi Anda bisa mengambil rata-rata.
Parthian Shot

3

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.


3
Re compiler mengurangi bug: Baik Python dan PHP secara teknis memiliki kompiler, mereka hanya tidak melakukan pengecekan yang sama seperti bahasa yang diketik secara statis. Saya juga tidak setuju bahwa pengecekan seperti itu memiliki efek signifikan pada penghitungan bug akhir karena hampir semua kesalahan yang dapat ditangkap oleh kompiler ditangkap dengan pengujian minimal.
Winston Ewert

3
Setuju bahwa bug yang dapat ditangkap oleh kompiler umumnya akan ditangkap dengan pengujian otomatis atau manual yang wajar. Perbedaannya adalah bahwa bahasa yang diketik secara statis memberi Anda ujian pertama (a) gratis, dan (b) sangat, sangat cepat. Rangkaian pengujian unit Ruby yang baik lebih baik daripada kompiler, tetapi Anda biasanya tidak dapat menjalankannya dengan cepat, Anda tidak mendapatkannya secara gratis, dan biasanya tidak akan menunjuk sedekat mungkin ke baris kode yang merupakan masalah.
Ken Smith

Tipe statis @KenSmith tidak gratis. courses.cs.washington.edu/courses/cse590n/10au/…
Hugo Wood

1

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.


1

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.


bagaimana ini diturunkan? SO menjadi penuh dengan badut
codyc4321

0

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.


2
Baris kode "metrik tidak berguna"? Tidak, ini merupakan perkiraan kasar dari kompleksitas program. Ini dapat bermanfaat karena mudah diukur dan juga terkait erat dengan waktu pengembangan.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.