it-swarm-id.com

Apa artinya menulis "kode yang baik"?

Dalam ini pertanyaan saya bertanya apakah menjadi penulis yang buruk menghalangi Anda dari menulis kode yang baik. Banyak jawaban yang 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"?

41
gablin

Coder yang baik seperti pemain biliar yang baik.

Ketika Anda melihat pemain biliar profesional, pada awalnya Anda mungkin tidak terkesan: "Tentu, mereka mendapatkan semua bola, tetapi mereka hanya memiliki tembakan mudah!" Ini karena, ketika pemain biliar menembak, dia tidak berpikir tentang bola apa yang akan masuk ke saku mana, dia juga memikirkan di mana bola isyarat akan berakhir . Menyiapkan tembakan 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 datang dengan konseptualisasi yang tepat dari masalah dan solusinya. Ketika kita tidak memahami suatu 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.

91
Macneil

WTF's per minute

( 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 baik" ke dalam aturan sehingga Anda dapat membiarkan komputer menentukan mengatakan "Ya, seni bagus" atau "Tidak, puisi yang buruk". Saat ini satu-satunya cara adalah untuk melihat betapa mudah dipahami kode itu untuk manusia lain.

49
user1249

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

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

7
mojuba

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 membuat modifikasi pada sistem yang Anda buat 6 bulan lalu dan dia tidak pernah sekalipun menanyakan pertanyaan kepada Anda
  4. Atasan Anda meminta Anda 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 mendapat untung.

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 beberapa pengingat. 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 efisiensi kejernihan, keanggunan , dan kejelasan

Sumber: MSDN

4
Chankey Pathak

Apakah ini tampak akrab?

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 bisa menjelaskan prinsip apa yang dilanggar, komentar saya diabaikan begitu saja dan pekerjaan terus berjalan. Merasakan bahwa harus ada cara untuk menjelaskan dan memberikan motivasi untuk "selera" 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 .

3
mlvljr

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);
1
bobah

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

alt text

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
Gary Rowe

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 dijelaskan, maka pembaca tersebut tidak boleh menulis kode ...

1
gbn

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 diorganisasikan secara bersih dan dapatkah saya menemukan kode tanpa terlalu banyak upaya?
  • Bagaimana kode diorganisasikan? Apakah didokumentasikan dengan jelas apa yang dilakukan 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 fungsi 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 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 bisa menjadi yang terbaik di dunia, tetapi mungkin masih menyusahkan jika desain keseluruhan aplikasi tidak masuk akal.

1
rjzii

Biarkan saya dengan baik hati 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 mendapatkan lebih 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 readible bisa sangat, sangat lambat. Solusi yang kurang mudah diatur dapat memberikan peningkatan kecepatan berlipat ganda. R adalah contoh yang bagus untuk 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 cerdas 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.

1
Joris Meys

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
chiurox

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

Kode Anda akan mengandung bug, akan mungkin diperpanjang dan digunakan kembali, dan seharusnya untuk difaktorkan ulang di beberapa titik - bahkan jika itu Jika Anda mengunjunginya kembali, kemungkinan besar Anda tidak akan tahu apa yang Anda lakukan sejak awal, untuk membantu diri sendiri dan tidak menghalangi.

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.

1
cjmUK