Apa itu kode negatif?

Jawaban:

501

Ini berarti mengurangi baris kode, dengan menghapus redundansi atau menggunakan konstruksi yang lebih ringkas.

Lihat misalnya anekdot terkenal ini dari tim pengembang Apple Lisa asli:

Ketika tim Lisa berusaha menyelesaikan perangkat lunak mereka pada tahun 1982, manajer proyek mulai meminta pemrogram untuk menyerahkan formulir mingguan yang melaporkan jumlah baris kode yang telah mereka tulis. Bill Atkinson menganggap itu konyol. Untuk minggu di mana ia telah menulis ulang rutinitas penghitungan wilayah QuickDraw menjadi enam kali lebih cepat dan 2000 baris lebih pendek, ia meletakkan "-2000" pada formulir. Setelah beberapa minggu, manajer berhenti memintanya untuk mengisi formulir, dan ia dengan senang hati menurutinya.

Thilo
sumber
257
Kesempurnaan tercapai, bukan ketika tidak ada lagi yang bisa ditambahkan, tetapi ketika tidak ada lagi yang harus diambil - Antoine de Saint-Exupéry
systempuntoout
7
Apakah #LOC ukuran yang baik untuk kualitas kode? Saya bisa 'Meminimalkan' kode C atau C ++ dan mengurangi jumlah baris secara signifikan tetapi itu akan menjadi mimpi buruk untuk dipertahankan.
JBRWilkinson
8
@systempuntout - dan kemudian ada Einsten "(Sebuah teori ilmiah) harus sesederhana mungkin, tetapi tidak lebih sederhana"
Jonathan Day
32
Tidak ada yang berjalan lebih cepat, atau lebih dapat diandalkan, atau membutuhkan lebih sedikit perawatan, selain kode yang tidak ada. "Ketika ragu, tanggalkan itu!"
TMN
4
@ JBRWilkinson: Saya akan mengatakan bahwa ada "sweet spot" tentang singkatnya kode. Secara umum, lebih pendek lebih baik, tetapi ada saatnya kode dapat tumbuh terlalu singkat dan tidak mudah untuk diuraikan ke programmer lain.
GordonM
131

Ada kutipan Bill Gates di sepanjang garis mengukur produktivitas pemrogram dengan garis kode seperti mengukur kemajuan pembangunan pesawat terbang berdasarkan beratnya.

Saya ingin menambahkan bahwa metrik LOC telah mendorong penggunaan bahasa yang terlalu bertele-tele dan sengaja menciptakan kembali roda untuk memenuhi kuota.

Kyralessa
sumber
30
Ya, itulah masalahnya dengan segala jenis metrik. Segera setelah Anda menggunakannya untuk menilai kinerja orang, mereka akan mulai bermain angka.
5
Adakah yang benar-benar pernah menggunakan LOC sebagai metrik kinerja? Saya hanya melihatnya digunakan untuk hal-hal seperti "bagaimana bug proyek yang kita bicarakan di sini?"
Michael Borgwardt
5
@Michael: ya. Sayangnya ya.
Michael Petrotta
4
Apakah kita berbicara tentang Bill G. yang sama yang memiliki perusahaan yang dengan metafora itu menghasilkan 10.000 jet GTON? :)
Daniel Mošmondor
37
Seorang programmer yang menulis kode untuk komputer onboard Space Shuttle mengatakan kepada saya bahwa ia harus memperhitungkan berat perangkat lunaknya! Perangkat lunak itu nyata (uang dibayarkan untuk itu); itu di pesawat ulang-alik; berat semua yang dimuat di shuttle harus diperhitungkan. Contoh pertama mengukur produktivitas programmer berdasarkan berat kode. (Nol tidak diizinkan, jadi ia menetapkan 0,00001 gram dan semuanya memuaskan.)
Mark Lutton
118

Ketika saya masih di sekolah menengah - dan ya, kami memiliki komputer di tahun 70-an, meskipun kami harus membuatnya dari kulit binatang menggunakan pisau batu - salah satu guru matematika mengadakan kontes pemrograman. Aturannya adalah bahwa program yang menang akan menjadi yang menghasilkan output yang benar, dan yang memiliki produk terkecil dari garis waktu kode waktu berjalan. Yaitu, jika program Anda mengambil, katakan 100 baris kode dan berlari selama 5 detik, skor Anda adalah 500. Jika orang lain menulis 90 baris kode dan berlari selama 6 detik, skornya adalah 540. Skor rendah menang, seperti golf.

Itu mengejutkan saya sebagai sistem penilaian yang brilian, memberi penghargaan baik atas keringkasan maupun kinerja.

Tetapi entri yang secara teknis memenuhi kriteria pemenang didiskualifikasi. Masalahnya adalah untuk mencetak daftar semua bilangan prima kurang dari 100. Entri yang didiskualifikasi terjadi seperti ini (sebagian besar siswa menggunakan BASIC saat itu):

100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"

Siswa yang menulis entri itu menunjukkan bahwa tidak hanya pendek dan sangat efisien, tetapi algoritme harus jelas bagi siapa pun yang memiliki pengetahuan pemrograman minimal, membuat program ini sangat dapat dipertahankan.

Jay
sumber
10
Lebih banyak bukti bahwa penghitungan baris kode adalah metrik yang sangat dapat dimainkan :-)
44
Program BASIC itu brilian! Agak mengecewakan bahwa guru mendiskualifikasi program. Bagaimanapun, tabel pencarian (yang programnya agak mirip) pasti dapat ditemukan dalam pemrograman dunia nyata.
Noctis Skytower
6
Seorang guru yang bijak mungkin telah menerima program BASIC ini dan menggunakannya untuk menyoroti pentingnya mendapatkan hak SRS. Mengingatkan saya pada seorang pelatih bisbol yang merasa sangat frustrasi dengan timnya sehingga untuk menunjukkan kepada mereka bagaimana cara bermain, dia mengambil tongkat pemukul, mendapat tiga pukulan berturut-turut dan tidak mau kalah, dia berteriak kepada timnya "Lihat! ***** sedang bermain. Sekarang ambil kelelawar dan mainkan dengan benar! " Juga mengingatkan saya pada orang yang menulis "penciptaan melihat pencipta dan memerah" dan memenangkan kontes esai 'anggur'.
Nav
3
@Nav: Mengingatkan saya pada cerita serupa yang dimulai dengan cara yang sama. Kemudian pelatih melempar bola ke udara, berayun, dan gagal. Dia melemparkannya ke udara lagi, berayun dan meleset. Dia melemparkannya ke udara untuk ketiga kalinya, berayun dan meleset. Lalu dia berkata kepada tim, "Lihat, ITULAH bagaimana kamu seharusnya melempar!" (Saya tidak tahu apa kaitan cerita ini dengan pengembangan perangkat lunak.)
Jay
13
Saya akan sangat marah jika saya didiskualifikasi karena ini. Masalah deterministik layak mendapatkan solusi deterministik, bukan? Ketika saya menulis aplikasi 'Hello World' saya tidak memberi kode untuk memeriksa apakah saya mengeja 'Hello' dengan benar.
Kirk Broadhurst
34

Ini lidah-di-pipi. Jika biaya Anda $ N per baris kode rata-rata, maka pengkodean "garis negatif" pasti pemenang.

Ini berarti, sebagai saran praktis, bahwa kode kecil yang menyelesaikan pekerjaan, jauh lebih baik daripada kode besar yang melakukan hal yang sama, semua hal lain dianggap sama.

Ira Baxter
sumber
2
Saya melihat dari mana Anda berasal, tetapi kode tapak kecil yang ringkas dan mudah dipahami jarang dicapai dalam sekali jalan. Biasanya ditulis sehingga berfungsi (banyak baris), optimalkan untuk kecepatan (baris lebih sedikit) dan optimalkan untuk pemeliharaan / keterbacaan (lebih sedikit baris masih). Biaya riil dengan pengembalian investasi yang panjang adalah langkah kedua dan ketiga, sehingga mereka sering dilewati seluruhnya. Ini seperti "ada yang murah, cepat dan bagus - Anda bisa memilih dua".
2
Sebenarnya, IME, mengoptimalkan untuk pemeliharaan / readibility sebenarnya dapat meningkatkan LOC, karena menulis ulang kode untuk membuatnya lebih mendokumentasikan diri cenderung juga membuatnya lebih bertele-tele.
1
@Visage: "... semua hal lain dianggap sama".
Ira Baxter
intinya adalah, saya pikir, bahwa semua hal lain tidak dapat sama antara kode ringkas dan kode verbose.
Tomas Narros
Alasan rata-rata baris kode biaya $ N adalah karena Anda pertama kali menghabiskan waktu menulis Xbaris. Kemudian, melalui beberapa iterasi, mengurangi produk akhir dengan Ygaris. Jadi, (X-Y)baris yang tersisa tampaknya sangat mahal karena pembantaian refactoring telah memotong semua cruft.
27

Menulis program yang sama dalam kode yang lebih sedikit adalah tujuan untuk semua orang.

Jika suatu program mengambil 200 LOC ke kode, dan saya menulisnya dalam 150, saya menulis -50 LOC. Jadi saya menulis kode negatif.

LucaB
sumber
3
Juga, lebih sedikit menulis LOC berarti Anda dapat membuat lebih sedikit kesalahan dan menemukannya dengan mudah-
LucaB
3
Tidak berlaku untuk Haskell dan bahasa lain yang dapat dikompresi menjadi derau acak. :)
Macke
1
Tentu, maksud saya bukanlah "mengompresi kode", tetapi menulis algoritma yang efisien yang menghasilkan lebih sedikit LOC :) +1 untuk komentar Anda.
LucaB
9

Jawaban Thilo mungkin paling akurat secara historis, tetapi metafora "kode negatif" juga dapat mencakup kinerja dan penggunaan memori - upaya penghargaan untuk menunda eksekusi atau alokasi sesuatu sampai benar-benar diperlukan.

Mentalitas "menunda-nunda" ini menghasilkan aksioma-aksioma seperti berkata, "Tidak melakukan apa-apa selalu lebih cepat daripada melakukan sesuatu", "Kode tercepat adalah kode yang tidak pernah dijalankan", dan "Jika Anda bisa menundanya cukup lama, Anda mungkin tidak perlu melakukannya "(merujuk pada penangguhan operasi mahal sampai benar-benar diperlukan)

Salah satu teknik untuk mewujudkan kode negatif adalah dengan menantang asumsi awal dan definisi masalah. Jika Anda dapat mendefinisikan kembali domain masalah / input sehingga "masalah lengket # 3" secara kategoris tidak mungkin, maka Anda tidak perlu menghabiskan waktu atau kode berurusan dengan masalah lengket # 3. Anda telah menghilangkan kode dengan mengoptimalkan desain.

dthorpe
sumber