Apa artinya menulis "kode yang baik"? [Tutup]


41

Dalam pertanyaan ini saya bertanya apakah menjadi penulis yang buruk menghalangi Anda dari menulis kode yang baik. Banyak jawaban dimulai dengan "itu tergantung pada apa yang Anda maksud dengan kode yang baik".

Tampaknya istilah "kode baik" dan "kode buruk" sangat subyektif. Karena saya memiliki satu pandangan, mungkin sangat berbeda dari pandangan orang lain tentang mereka.

Jadi apa artinya menulis "kode yang baik"? Apa itu "kode yang baik"?


15
Kode yang baik adalah jika Anda melihatnya setelah dua tahun dan pikiran pertama Anda bukanlah "Dude, wtf".
Bobby

Jawaban:


91

Seorang programmer yang baik seperti pemain biliar yang baik.

Ketika Anda melihat pemain biliar profesional, pada awalnya Anda mungkin tidak akan terkesan: "Tentu, mereka mendapatkan semua bola, tetapi mereka hanya memiliki tembakan mudah!" Ini karena, ketika pemain biliar melakukan tendangannya, dia tidak memikirkan bola apa yang akan masuk ke saku mana, dia juga memikirkan di mana bola isyarat akan berakhir . Mengatur untuk pemotretan berikutnya membutuhkan keterampilan dan latihan yang luar biasa, tetapi itu juga berarti bahwa itu terlihat mudah.

Sekarang, membawa metafora ini ke kode, seorang pembuat kode yang baik menulis kode yang sepertinya mudah dan mudah dilakukan . Banyak contoh oleh Brian Kernighan dalam bukunya mengikuti pola ini. Bagian dari "trik" akan muncul dengan konseptualisasi masalah yang tepat dan solusinya . Ketika kita tidak memahami masalah dengan cukup baik, kita cenderung mempersulit solusi kita, dan kita akan gagal melihat gagasan yang menyatukan.

Dengan konseptualisasi masalah yang tepat, Anda mendapatkan segalanya: keterbacaan, pemeliharaan, efisiensi, dan kebenaran. Karena solusinya tampak sangat mudah, kemungkinan akan ada lebih sedikit komentar, karena penjelasan tambahan tidak diperlukan. Seorang programmer yang baik juga dapat melihat visi jangka panjang dari produk, dan membentuk konseptualisasi mereka sesuai.


10
"Seorang pembuat kode yang baik menulis kode yang sepertinya mudah dan langsung dilakukan." << PERSIS! Saya pikir ini karena orang biasanya berpikir pembuat kode yang baik adalah seseorang yang bisa menulis hack yang sangat "pintar". Jika kodenya bersih dan tidak terlalu "pintar", pasti mudah, bukan?
hasen

3
2 sen saya: ketika Anda memiliki bahasa dengan refactor otomatis MUDAH - Java dan C # adalah dua contoh yang saya tahu terbaik - mudah untuk beralih ke kode yang baik secara iteratif. Kalau tidak, Anda harus mengonseptualisasikan dengan baik sejak awal, tetapi ada semacam masalah ayam-telur di sana.
Dan Rosenstark

3
Beberapa algoritma secara intrinsik kompleks. Seorang programmer yang baik seharusnya tidak memiliki masalah menuliskannya ketika mereka benar - benar diperlukan - dan menjaganya agar tetap dapat dibaca.
J-16 SDiZ

2
@ Hasenj: ya, ini karena lemma ini: orang bodoh menulis kode yang dipahami kompiler. Orang pintar menulis kode yang dimengerti orang bodoh.
v.oddou

49

WTF per menit

( asli )


EDIT: Ide dasarnya adalah "Kualitas Kode" tidak dapat dimasukkan ke dalam aturan, dengan cara yang sama Anda tidak dapat memasukkan "Seni bagus" atau "Puisi yang bagus" ke dalam aturan sehingga Anda dapat membiarkan komputer menentukan mengatakan "Ya, seni bagus" atau "Tidak, puisi yang buruk". Saat ini satu-satunya cara adalah dengan melihat betapa mudah dipahami kode itu untuk manusia lain.


1
Kami memiliki ini macet di papan tulis kami di tempat kerja :-)
Tidak ada yang

1
@Cape Cod Gunny Berada dalam buku Paman Bob juga
mlvljr

2
Selain menjadi kartun yang hebat, saya pikir itu benar-benar sampai ke titik - kode yang baik adalah kode yang orang lain senang membaca dan memelihara.
FinnNk

1
Jadi benar, kode yang baik adalah kode yang tidak buruk. Misalnya sulit untuk mendefinisikan kode yang baik, lebih mudah untuk mendefinisikan kode yang buruk.
Ernelli

5
Biasanya saya menemukan "WTF?" Dalam rapat kode yang baik segera ditindaklanjuti dengan "Oooooh Oke ... Saya melihat apa yang Anda lakukan thar."
AndrewKS

7

Sebenarnya tidak ada kriteria yang baik selain seberapa cepat Anda dapat memahami kode. Anda membuat kode Anda terlihat bagus dengan menemukan kompromi yang sempurna antara ringkas dan mudah dibaca.

"WTF's per minute" (di atas) benar tetapi itu hanya akibat wajar dari aturan yang lebih umum. Semakin banyak WTF, semakin lambat pemahamannya.


1
@ rmx: mendefinisikan "melakukan pekerjaan dengan baik"
mojuba

2
Nah, RemoveCustomermetode itu benar-benar menghilangkan pelanggan tanpa mengacaukan. Anda dapat menghabiskan waktu berjam-jam agar terlihat cantik, tetapi itu tidak berarti itu benar-benar berfungsi. 'Seberapa cepat Anda dapat memahami kode' bukan satu-satunya kriteria untuk 'kode yang baik' adalah apa yang saya katakan.
Tidak ada yang

2
@ rmx: tetapi bebas bug tersirat, bukan? Jika kode Anda tidak melakukan pekerjaan dengan benar, itu bukan kode (belum).
mojuba

4
@ rmx: sebenarnya, tidak. Jika kode Anda mudah dipahami, maka kesimpulannya mudah dipahami jika itu berfungsi dengan buruk. OTOH, jika sulit untuk dipahami, sulit untuk memahami apakah itu berfungsi sama sekali.
pembuat pil KB

2
@ rmx: PS sederhananya, penurunan Anda () adalah WTF klasik dan dengan demikian memperlambat pemahaman bagian-bagian kode di mana fungsi ini digunakan
mojuba

5

Anda tahu Anda menulis kode yang baik ketika ...

  1. Pelanggan itu senang
  2. Rekan kerja meminjam kode Anda sebagai titik awal
  3. Pria baru itu baru saja diberitahu untuk melakukan modifikasi pada sistem yang Anda buat 6 bulan lalu dan ia tidak pernah sekalipun pernah mengajukan pertanyaan kepada Anda
  4. Bos Anda meminta Anda untuk mengembangkan widget baru untuk digunakan tim
  5. Anda melihat kode yang Anda tulis hari ini dan berkata pada diri sendiri, "Seandainya saya menulis kode seperti ini dua tahun lalu"

Bagaimana Anda mengukur apakah kodenya baik ...

  • Apa waktu respon?
  • Berapa banyak perjalanan pulang pergi ke server yang dilakukan?
  • Apakah Anda secara pribadi menggunakan aplikasi atau menurut Anda itu kikuk?
  • Apakah Anda akan membangunnya dengan cara yang sama lain kali?

Kode yang bagus berfungsi saat seharusnya. Kode yang baik dapat dengan mudah dimodifikasi ketika perlu. Kode yang baik dapat digunakan kembali untuk menghasilkan keuntungan.


2
"Pelanggan senang" adalah hal yang biasa dalam hal ini.

1
@TRA - Jika pelanggan senang itu berarti Anda memahami persyaratan dan memberikan solusi yang mereka harapkan.
Michael Riley - AKA Gunny

6
yakin tapi kode buruk dapat melakukan hal yang sama.

4

Kode yang

  1. bebas serangga

  2. dapat digunakan kembali

  3. independen

  4. kurang kompleks

  5. didokumentasikan dengan baik

  6. mudah untuk mengejar

disebut kode yang baik.

Program yang bagus bekerja dengan sempurna dan tidak memiliki bug. Tetapi kualitas internal apa yang menghasilkan kesempurnaan seperti itu? Ini bukan misteri, kita hanya perlu mengingatkan sekali-sekali. Apakah Anda mengkode dalam C / C ++, C #, Java, Basic, Perl, COBOL, atau ASM, semua pemrograman yang baik menunjukkan kualitas yang sama dengan waktu: kesederhanaan, keterbacaan, modularitas, pelapisan, desain, efisiensi, keanggunan, dan kejelasan efisiensi, keanggunan , dan kejelasan

Sumber: MSDN


Kesederhanaan, keterbacaan, keanggunan dan kejelasan semuanya adalah hal yang sama. Modularitas dan layering hanyalah metode untuk membuat kode Anda jelas dan elegan. Satu-satunya hal yang tersisa dalam daftar adalah efisiensi, yang tersirat, dan selain itu sering kali masalah kompromi antara efisiensi dan kejelasan.
mojuba


2
Kode dapat bebas bug?
Casey Patton

Tidak, tidak bisa. (Praktis)
Chankey Pathak

Efisien harus ditambahkan ke daftar Anda. Kecepatan tidak selalu merupakan indikator utama kode yang baik, tetapi kode yang baik seharusnya tidak terlalu lambat atau boros.
Caleb

3

Apakah ini tampak familier?

Philips memberi saya kesempatan untuk menonton desain produk baru. Seiring perkembangannya, saya menjadi semakin gelisah dan mulai menceritakan kekhawatiran saya kepada atasan saya. Saya berulang kali mengatakan kepadanya bahwa desainnya tidak "bersih" dan bahwa itu harus "indah" seperti desain Dijkstra yang indah. Dia tidak menemukan ini sebagai komentar yang bermanfaat. Dia mengingatkan saya bahwa kami adalah insinyur, bukan seniman. Dalam benaknya aku hanya mengungkapkan seleraku dan dia ingin tahu kriteria apa yang aku gunakan dalam membuat penilaian. Saya tidak bisa memberitahunya! Karena saya tidak dapat menjelaskan prinsip-prinsip apa yang dilanggar, komentar saya diabaikan begitu saja dan pekerjaan terus berjalan. Merasakan bahwa harus ada cara untuk menjelaskan dan memberikan motivasi untuk "rasa" saya, Saya mulai mencoba menemukan prinsip yang akan membedakan desain yang baik dari yang buruk. Insinyur sangat pragmatis; mereka mungkin mengagumi keindahan, tetapi mereka mencari kegunaan. Saya mencoba mencari penjelasan mengapa "kecantikan" bermanfaat.

Silakan lihat sisanya di sini .


1
Karena tautan di pos @ mlvljr rusak, berikut ini tautan ke laman Google Buku: books.google.co.in/…
balajeerc

@balajeerc Terima kasih (saya juga memperbaiki tautannya, jadi ini menunjuk ke versi pdf yang sama dengan Springer-host) :)
mlvljr

1

terlepas dari kriteria kualitas kode alami (minimum salin / tempel, tidak ada spaghetti, dll.) kode industri yang baik harus selalu terlihat agak naif, agak terlalu bertele-tele, seperti

int key = i;
const bool do_not_create = false;
Record r = cache.get(key, do_not_create);
++i;

sebagai lawan

Record r = cache.get(i++, false);

Tetapi apakah do_not_create = falsemaksudnya "lulus falsesebagai do_not_createargumen sehingga akan dibuat" atau "lulus falsesebagai do_createargumen sehingga tidak akan dibuat"? Dalam bahasa di mana Anda dapat menggunakan nama argumen yang saya inginkan cache.get (key:i, create: false); i += 1;.
PJTraill

1

Mungkin jawaban dengan mengilustrasikan yang sebaliknya akan membantu (plus itu alasan untuk mendapatkan XKCD di sini).

teks alternatif

Kode yang bagus

  • mudah dimengerti,
  • mudah dirawat,
  • tidak mencoba menyelesaikan semua masalah hanya yang ada di tangan
  • hidup untuk waktu yang lama tanpa membuat pengembang mencari alternatif

Contohnya termasuk

  • Apache Commons
  • Kerangka pegas
  • Kerangka kerja hibernasi

1

Saya hanya akan pergi dengan "dipelihara"

Semua kode harus dipertahankan: tidak perlu ada tugas yang dibuat lebih sulit dari yang diperlukan

Jika ada pembaca yang tidak memahami persyaratan sederhana ini atau perlu menjabarkannya, maka pembaca itu tidak boleh menulis kode ...


1

Kode yang baik akan berbeda untuk setiap orang dan bahasa yang mereka gunakan juga berdampak pada apa yang dianggap sebagai kode yang baik. Secara umum ketika saya mendekati suatu proyek saya mencari hal-hal berikut:

  • Bagaimana proyek ini diorganisasikan? Apakah file sumber diatur dengan cara yang bersih dan dapatkah saya menemukan kode tanpa terlalu banyak upaya?
  • Bagaimana kode ini disusun? Apakah didokumentasikan dengan jelas apa yang dilakukan oleh kode dalam file, seperti melalui penggunaan header file, atau melalui penggunaan setiap kelas yang berada di file sendiri? Apakah ada fungsi dalam file yang tidak lagi digunakan dalam aplikasi?
  • Bagaimana fungsinya diatur? Apakah ada pola yang jelas di mana variabel dideklarasikan, atau apakah itu pola yang cukup acak? Apakah kode memiliki alur logis untuk itu dan menghindari struktur kontrol yang tidak perlu? Apakah semuanya jelas didokumentasikan dengan kode yang mendokumentasikan diri sendiri di mana perlu dan komentar dengan jelas menyatakan mengapa dan / atau bagaimana apa yang dilakukan kode?

Di luar semua ini, apakah desain aplikasi masuk akal secara keseluruhan? Kode yang berada dalam aplikasi dapat menjadi yang terbaik di dunia, tetapi mungkin masih menyusahkan jika desain keseluruhan aplikasi tidak masuk akal.


1

Izinkan saya dengan tidak setuju pada readibility. Tidak, tidak sepenuhnya: Kode yang baik harus dapat dibaca, dan itu dapat dengan mudah dicapai dengan komentar yang cukup.

Tapi saya mempertimbangkan dua jenis WTF: yang mana Anda bertanya-tanya apakah programmer lebih jauh dari pemrograman 101, dan yang mana Anda benar-benar tidak memahami keaslian kode. Beberapa kode dapat terlihat sangat aneh pada awalnya, tetapi sebenarnya merupakan solusi yang sangat inventif untuk masalah yang sulit. Yang kedua tidak harus dihitung dalam WTF-meter, dan dapat dihindari dengan komentar.

Kode yang sangat mudah diatur bisa sangat, sangat lambat. Solusi yang kurang mudah diatur dapat memberikan peningkatan kecepatan berlipat ganda. R adalah contoh yang bagus dari bahasa yang sering kali benar. Seseorang suka menghindari for-loop di sana sebanyak mungkin. Secara umum, saya akan menganggap kode tercepat kode yang lebih baik meskipun kurang mudah diatur. Yaitu, jika peningkatannya cukup besar tentunya, dan cukup banyak komentar dimasukkan untuk menjelaskan apa yang dilakukan kode.

Terlebih lagi, manajemen memori dapat menjadi sangat penting dalam banyak aplikasi ilmiah. Kode yang sangat mudah diatur, cenderung agak ceroboh dalam penggunaan memori: hanya ada lebih banyak objek yang dibuat. Dalam beberapa kasus, penggunaan memori secara pintar membuat kode lagi kurang dapat diatur. Tetapi jika Anda menyulap sekitar gigabyte urutan DNA misalnya, memori adalah faktor penting. Sekali lagi, saya menganggap semakin sedikit memori-intensif kode kode yang lebih baik, terlepas dari readibility.

Jadi ya, readibility penting untuk kode yang baik. Saya tahu adagium dari Uwe Liggis: Berpikir sakit dan komputer itu murah. Tetapi di bidang saya (genomik statistik), waktu komputasi dalam seminggu dan penggunaan memori lebih dari 40 Gb tidak dianggap abnormal. Jadi peningkatan dua kali lipat kecepatan dan setengah dari memori bernilai jauh lebih banyak daripada sedikit tambahan kemampuan.


Tidak ada aturan / aturan tanpa pengecualian
user2664856

1
Biarkan saya tidak setuju dengan ketidaksetujuan Anda: Anda mengatakan bahwa dalam bidang Anda, kecepatan sangat penting dan mengatakan bahwa itu lebih penting daripada keterbacaan. Saya tidak setuju, Anda harus berusaha menggunakan keseimbangan yang tepat. Jika kecepatan tidak diperlukan, misalnya untuk antarmuka tingkat tinggi, Anda mungkin lebih suka sesuatu yang mudah dipertahankan, jika kecepatan diperlukan maka saya setuju dengan Anda. Daripada aturan keras lebih baik menggunakan akal sehat dan Anda harus menghindari optimasi prematur pula.
BlueTrin

@ BlueTrin Mengapa tidak kedua otak mengkompilasi kode sumber hi-perf tersebut, dan juga mendokumentasikan apa yang terjadi di sana (di sana di komentar)?
mlvljr

1

Sejauh yang saya tahu ... Saya tahu saya menulis kode yang baik ketika rekan kerja yang bekerja pada proyek lain datang dan dapat melompat masuk dan memahami apa yang saya lakukan tanpa saya memeriksa setiap blok kode dan menunjukkan apa yang dilakukannya.
Alih-alih dia berkata, "Tunggu sebentar, apa ?!" Dia berkata, "Oh, baiklah, saya melihat apa yang Anda lakukan di sana."

Kode yang baik juga tidak memiliki banyak solusi tersembunyi atau 'peretasan.' Baris ketika, saat Anda menulisnya, Anda juga berkata pada diri sendiri, "Saya tahu ini bukan cara yang baik untuk melakukannya, tapi saya hanya harus melakukannya dengan cara ini untuk saat ini. Saya akan mengingatkan sendiri untuk memperbaikinya nanti ... "


1

Ada banyak fitur kode 'baik', tetapi yang paling penting, IMHO, adalah keterbacaan dan pemeliharaan.

Kode Anda akan mengandung bug, mungkin akan diperluas dan digunakan kembali, dan harus difaktorkan ulang pada beberapa titik - bahkan jika Anda mengunjunginya kembali, kemungkinannya adalah bahwa Anda tidak akan memiliki petunjuk apa-apa Anda lakukan di tempat pertama, untuk melakukan kebaikan pada diri sendiri dan tidak menempatkan hambatan di jalan.

Tentu, gunakan algoritme yang rumit-namun-tidak-efisien, tetapi pastikan Anda menghabiskan sedikit waktu untuk mendokumentasikannya, tetapi jika tidak buatlah kode Anda jelas dan konsisten.

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.