Seperti apa kode programmer yang baik? [Tutup]

Saya seorang programmer hobi (mulai dengan VBA untuk membuat excel lebih cepat) dan telah bekerja dengan VB.NET / C # .NET dan saya sedang mencoba untuk belajar ADO.NET.

Sebuah segi dari pemrograman yang selalu membuat saya frustrasi adalah seperti apa 'bagus' itu? Saya bukan seorang profesional jadi tidak banyak yang bisa dibandingkan. Apa yang membuat programmer lebih baik? Apakah itu:

• Mereka memiliki pemahaman yang lebih baik tentang semua objek / kelas / metode dalam bahasa tertentu?
• Program mereka lebih efisien?
• Desain program mereka jauh lebih baik dalam hal dokumentasi yang lebih baik, pilihan nama yang baik untuk fungsi, dll.?

Dengan kata lain, jika saya melihat kode programmer profesional, apa hal pertama yang saya perhatikan tentang kode mereka relatif terhadap saya? Misalnya, saya membaca buku-buku seperti 'Professional ASP.NET' oleh Wrox press. Apakah contoh kode dalam buku itu 'kelas dunia'? Apakah itu puncaknya? Apakah ada programmer papan atas yang melihat kode itu dan menganggapnya sebagai kode yang bagus?

Daftar di bawah ini tidak lengkap, tetapi ini adalah hal-hal yang saya pikirkan dalam mempertimbangkan pertanyaan Anda.

• Kode yang baik diatur dengan baik. Data dan operasi di kelas cocok satu sama lain. Tidak ada ketergantungan asing antar kelas. Tidak terlihat seperti "spageti".

• Komentar kode yang baik menjelaskan mengapa sesuatu dilakukan bukan apa yang dilakukan. Kode itu sendiri menjelaskan apa yang telah dilakukan. Kebutuhan akan komentar harus diminimalkan.

• Kode yang baik menggunakan konvensi penamaan yang bermakna untuk semua kecuali objek yang paling sementara. nama sesuatu bersifat informatif tentang kapan dan bagaimana menggunakan objek tersebut.

• Kode yang bagus sudah teruji dengan baik. Tes berfungsi sebagai spesifikasi yang dapat dieksekusi dari kode dan contoh penggunaannya.

• Kode yang baik bukanlah "pintar". Itu melakukan hal-hal dengan cara yang lugas dan jelas.

• Kode yang baik dikembangkan dalam unit komputasi yang kecil dan mudah dibaca. Unit ini digunakan kembali di seluruh kode.

Saya belum membacanya, tetapi buku yang akan saya baca tentang topik ini adalah Kode Bersih oleh Robert C. Martin.

Hal pertama yang Anda perhatikan adalah bahwa kode mereka mengikuti gaya pengkodean yang konsisten . Mereka selalu menulis blok struktur yang sama, membuat indentasi secara religius, dan berkomentar jika sesuai.

Hal kedua yang Anda perhatikan adalah bahwa kode mereka tersegmentasi menjadi metode / fungsi kecil yang mencakup tidak lebih dari beberapa lusin baris paling banyak. Mereka juga menggunakan nama metode yang mendeskripsikan diri sendiri dan umumnya kode mereka sangat mudah dibaca.

Hal ketiga yang Anda perhatikan, setelah Anda mengotak-atik kode sedikit adalah bahwa logikanya mudah diikuti, mudah dimodifikasi - dan karenanya mudah dipelihara.

Setelah itu, Anda memerlukan pengetahuan dan pengalaman dalam teknik desain perangkat lunak untuk memahami pilihan spesifik yang mereka ambil untuk membangun arsitektur kode mereka.

Mengenai buku, saya belum pernah melihat banyak buku di mana kodenya bisa dianggap "kelas dunia". Dalam buku, mereka mencoba menyajikan contoh sederhana, yang mungkin relevan untuk memecahkan masalah yang sangat sederhana tetapi tidak mencerminkan situasi yang lebih kompleks.

Mengutip Fowler, meringkas keterbacaan:

Setiap orang bodoh dapat menulis kode yang dapat dimengerti oleh komputer.
Pemrogram yang baik menulis kode yang bisa dipahami manusia.

'kata nough.

Secara pribadi, saya harus mengutip "The Zen of Python" oleh Tim Peters. Ini memberi tahu programmer Python seperti apa tampilan kode mereka, tetapi saya menemukan bahwa itu berlaku pada dasarnya untuk semua kode.

Cantik itu lebih baik dari pada jelek.
Eksplisit lebih baik daripada implisit.
Sederhana lebih baik daripada kompleks.
Kompleks lebih baik daripada rumit.
Datar lebih baik dari pada bersarang.
Sparse lebih baik daripada padat.
Keterbacaan itu penting.
Kasus khusus tidak cukup istimewa untuk melanggar aturan.
Meskipun kepraktisan mengalahkan kemurnian.
Kesalahan tidak boleh lewat diam-diam.
Kecuali dibungkam secara eksplisit.
Dalam menghadapi ambiguitas, tolak godaan untuk menebak.
Seharusnya ada satu - dan sebaiknya hanya satu --cara yang jelas untuk melakukannya.
Meskipun cara itu mungkin tidak terlihat pada awalnya kecuali Anda orang Belanda.
Sekarang lebih baik daripada tidak sama sekali.
Meskipun tidak pernah lebih baik daritepat sekarang.
Jika implementasinya sulit dijelaskan, itu ide yang buruk.
Jika penerapannya mudah dijelaskan, mungkin itu ide yang bagus.
Namespaces adalah salah satu ide bagus - mari kita lakukan lebih banyak lagi!

Kode adalah puisi.

Mulailah dari titik logika ini dan Anda dapat memperoleh banyak kualitas kode yang diinginkan. Yang terpenting, amati bahwa kode dibaca jauh lebih banyak daripada yang tertulis, maka tulislah kode untuk pembaca. Tulis ulang, ganti nama, edit, dan refactor untuk pembaca.

Sebuah tindak lanjut wajar:

Pembaca adalah Anda pada waktu n sejak tanggal pembuatan kode. Hasil penulisan kode untuk pembaca adalah fungsi n yang meningkat secara monoton. Seorang pembaca yang melihat kode Anda untuk pertama kalinya ditunjukkan dengan n == tak terhingga.

Dengan kata lain, semakin besar jeda waktu dari saat Anda menulis kode hingga saat Anda mengunjungi kembali kode tersebut, semakin Anda akan menghargai upaya Anda untuk menulis untuk pembaca. Juga, siapa pun yang Anda berikan kode Anda akan mendapatkan keuntungan besar dari kode yang ditulis dengan pembaca sebagai pertimbangan utama.

Akibat wajar kedua:

Kode yang ditulis tanpa pertimbangan bagi pembaca bisa jadi sangat sulit untuk dipahami atau digunakan. Ketika pertimbangan untuk pembaca turun di bawah ambang tertentu, pembaca mendapatkan lebih sedikit nilai dari kode daripada nilai yang diperoleh dengan menulis ulang kode. Ketika ini terjadi, kode sebelumnya dibuang dan, tragisnya, banyak pekerjaan diulangi selama penulisan ulang.

Akibat wajar ketiga:

Akibat wajar dua telah diketahui berulang beberapa kali dalam lingkaran setan kode yang didokumentasikan dengan buruk diikuti dengan penulisan ulang paksa.

Saya telah memprogram selama 28 tahun dan saya merasa ini pertanyaan yang sulit untuk dijawab. Bagi saya, kode yang baik adalah paket yang lengkap. Kode ditulis dengan rapi, dengan variabel dan nama metode yang berarti. Ini memiliki komentar yang ditempatkan dengan baik yang mengomentari maksud kode dan tidak hanya memuntahkan kode yang sudah Anda baca. Kode melakukan apa yang seharusnya dilakukan dengan cara yang efisien, tanpa membuang sumber daya. Itu juga harus ditulis dengan perhatian pada pemeliharaan.

Intinya adalah bahwa itu memiliki arti yang berbeda bagi orang yang berbeda. Apa yang mungkin saya beri label sebagai kode bagus yang mungkin dibenci orang lain. Kode yang baik akan memiliki beberapa ciri umum yang menurut saya telah saya identifikasi di atas.

Hal terbaik yang dapat Anda lakukan adalah mengekspos diri Anda pada kode. Lihat kode orang lain. Proyek Open Source adalah sumber yang bagus untuk itu. Anda akan menemukan kode yang baik dan kode yang buruk. Semakin Anda melihatnya, semakin baik Anda mengenali apa yang Anda tentukan sebagai kode baik dan kode buruk.

Akhirnya Anda akan menjadi hakim Anda sendiri. Ketika Anda menemukan gaya dan teknik yang Anda sukai untuk mengadopsinya, lama kelamaan Anda akan menemukan gaya Anda sendiri dan itu akan berubah seiring waktu. Tidak ada orang di sini yang dapat melambaikan tongkat dan mengatakan apa yang baik dan apa pun yang buruk.

Baca buku Kode Lengkap. Ini menjelaskan banyak ide tentang bagaimana menyusun kode dan alasan untuk melakukannya. Membacanya akan mengurangi waktu Anda untuk memperoleh pengalaman yang diperlukan untuk membedakan yang baik dari yang buruk.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Saya sendiri telah memprogram selama hampir 10 tahun dan telah bekerja dengan orang lain, saya dapat mengatakan tanpa prasangka bahwa tidak ada perbedaan antara programmer yang baik dan kode programmer rata-rata

Semua pemrogram di tingkat yang kompeten:

• Komentar dengan Benar
• Struktur Secara Efisien
• Dokumen dengan Bersih

Saya pernah mendengar seorang rekan kerja berkata, " Saya selalu berpikiran logis dan rasional. Saya pikir itulah sebabnya saya senang berkembang "

Itu menurut saya, adalah pikiran seorang programmer rata-rata. Orang yang melihat dunia dalam kerangka aturan dan logika dan pada akhirnya mematuhi aturan tersebut saat merancang dan menulis program.

Pemrogram ahli, memahami aturan, tetapi juga konteksnya. Hal ini pada akhirnya mengarahkan mereka pada ide-ide dan implementasi baru, ciri dari programmer ahli. Pemrograman pada akhirnya merupakan bentuk seni.

Singkatnya, kode programmer yang baik dapat dibaca dan dipahami.

Menurut pendapat saya, kode programmer yang baik adalah bahasa-agnostik ; kode yang ditulis dengan baik dapat dibaca dan dipahami dalam waktu singkat dengan pemikiran minimal, terlepas dari bahasa pemrograman yang digunakan. Apakah kodenya ada di Java, Python, C ++ atau Haskell, kode yang ditulis dengan baik dapat dimengerti oleh orang-orang yang bahkan tidak memprogram dalam bahasa tertentu itu.

Beberapa karakteristik kode yang mudah dibaca adalah, metode yang dinamai dengan baik, tidak adanya "trik" dan "pengoptimalan" yang berbelit-belit, kelas yang dirancang dengan baik, dan lain-lain. Seperti yang telah disebutkan orang lain, gaya pengkodean konsisten, ringkas dan lurus ke depan .

Misalnya, beberapa hari yang lalu, saya sedang melihat kode untuk TinyMCE untuk menjawab salah satu pertanyaan di Stack Overflow. Itu ditulis dalam JavaScript, bahasa yang jarang saya gunakan. Namun, karena gaya pengkodean dan komentar yang disertakan, bersama dengan penataan kode itu sendiri, itu cukup dapat dimengerti, dan saya dapat menavigasi kode dalam beberapa menit.

Satu buku yang cukup membuka mata saya dalam hal membaca kode programmer yang baik adalah Beautiful Code . Ini memiliki banyak artikel yang ditulis oleh penulis dari berbagai proyek pemrograman dalam berbagai bahasa pemrograman. Namun, ketika saya membacanya, saya dapat memahami apa yang penulis tulis dalam kodenya meskipun saya tidak pernah memprogram dalam bahasa tertentu itu.

Mungkin yang harus kita ingat adalah bahwa pemrograman juga tentang komunikasi, tidak hanya kepada komputer tetapi kepada orang-orang , jadi kode programmer yang baik hampir seperti buku yang ditulis dengan baik, yang dapat mengkomunikasikan kepada pembaca tentang ide-ide yang ingin disampaikan .

• Mudah dibaca
• mudah untuk ditulis
• mudah dirawat

yang lainnya adalah kerawang

Kode yang baik harus mudah dipahami.
Ini harus dikomentari dengan baik.
Bagian yang sulit harus dikomentari dengan lebih baik.

Kode yang bagus dapat dibaca. Anda tidak akan kesulitan memahami apa yang dilakukan kode pada pembacaan pertama kode yang ditulis oleh programmer profesional yang baik.

Daripada mengulangi saran bagus orang lain, saya malah akan menyarankan Anda membaca buku Code Complete oleh Steve McConnell

Pada dasarnya ini adalah buku yang dikemas penuh dengan praktik terbaik pemrograman untuk fungsionalitas dan gaya.

[Jawaban yang murni subyektif]
Bagi saya, kode yang baik adalah suatu bentuk seni, sama seperti lukisan. Saya mungkin melangkah lebih jauh dan mengatakan bahwa itu sebenarnya adalah gambar yang mencakup karakter, warna, "bentuk" atau "struktur" kode, dan dengan semua ini sangat mudah dibaca / tampil. Kombinasi keterbacaan, struktur (misalnya kolom, lekukan, bahkan nama variabel dengan panjang yang sama!), Warna (nama kelas, nama variabel, komentar, dll.) Semuanya membuat apa yang saya suka lihat sebagai gambar "indah" yang bisa membuat saya sangat bangga atau sangat membenci kode saya sendiri.

(Seperti yang dikatakan sebelumnya, jawaban yang sangat subjektif. Maaf untuk bahasa Inggris saya.)

Saya mendukung rekomendasi "Kode Bersih" Bob Martin.

"Beautiful Code" sangat terkenal beberapa tahun lalu.

Semua buku McConnell layak dibaca.

Mungkin "The Pragmatic Programmer" juga bisa membantu.

%

Hanya ingin menambahkan 2 sen saya ... komentar dalam kode Anda - dan kode Anda sendiri, secara umum - harus mengatakan apa yang dilakukan kode Anda, sekarang bagaimana melakukannya. Setelah Anda memiliki konsep kode 'klien', yaitu kode yang memanggil kode lain (contoh paling sederhana adalah kode yang memanggil metode), Anda harus selalu khawatir tentang membuat kode Anda dapat dipahami dari perspektif "klien". Saat kode Anda berkembang, Anda akan melihat bahwa ini ... eh, bagus.

Banyak hal lain tentang kode yang baik adalah tentang lompatan mental yang akan Anda buat (pasti, jika Anda memperhatikan) ... 99% di antaranya berkaitan dengan melakukan sedikit lebih banyak pekerjaan sekarang untuk menghemat banyak bekerja nanti, dan dapat digunakan kembali. Dan juga dengan melakukan hal-hal yang benar: Saya hampir selalu ingin menggunakan cara lain daripada menggunakan ekspresi reguler, tetapi setiap kali saya memahaminya, saya mengerti mengapa semua orang menggunakannya dalam setiap bahasa yang saya gunakan (itu muskil, tapi bekerja dan mungkin tidak bisa lebih baik).

Mengenai apakah akan melihat buku, saya akan mengatakan secara pasti bukan menurut pengalaman saya. Lihatlah API dan kerangka kerja dan konvensi kode dan kode orang lain dan gunakan naluri Anda sendiri, dan cobalah untuk memahami mengapa hal-hal seperti itu dan apa implikasinya. Hal yang hampir tidak pernah dilakukan oleh kode dalam buku adalah merencanakan hal yang tidak direncanakan, yang merupakan inti dari pemeriksaan kesalahan. Ini hanya terbayar ketika seseorang mengirimi Anda email dan berkata, "Saya mendapat kesalahan 321" alih-alih "hai, aplikasi rusak, yo."

Kode yang baik ditulis dengan memikirkan masa depan, baik dari sudut pandang programmer maupun dari sudut pandang pengguna.

Ini dijawab dengan cukup baik dalam buku Fowler, "Refactoring", Ini adalah tidak adanya semua "bau" yang dia gambarkan di seluruh buku.

Saya belum pernah melihat 'Professional ASP.NET', tetapi saya akan terkejut jika itu lebih baik dari OK. Lihat pertanyaan ini untuk beberapa buku dengan kode yang sangat bagus. (Ini bervariasi, tentu saja, tetapi jawaban yang diterima di sana sulit dikalahkan.)

Ini sepertinya (seharusnya) sebuah FAQ. Ada artikel ACM tentang kode cantik baru-baru ini. Tampaknya ada banyak penekanan pada yang mudah dibaca / dipahami. Saya akan mengkualifikasinya dengan "mudah dibaca / dipahami oleh pakar domain". Pemrogram yang benar-benar baik cenderung menggunakan algoritme terbaik (alih-alih algoritme O (n ^ 2) yang naif, mudah dipahami) untuk masalah apa pun, yang mungkin sulit diikuti, jika Anda tidak terbiasa dengan algoritme tersebut, bahkan jika algoritmanya bagus. programmer memberikan referensi ke algoritma.

Tidak ada yang sempurna termasuk programmer yang baik tapi kode mereka cenderung berusaha untuk:

1. Ketepatan dan efisiensi dengan algoritme yang terbukti (bukan peretasan naif dan adhoc)
2. Kejelasan (komentar untuk maksud dengan mengacu pada algoritma non-sepele)
3. Kelengkapan untuk mencakup dasar-dasar (konvensi pengkodean, pembuatan versi, dokumentasi, pengujian unit, dll.)
4. Kesederhanaan (KERING)
5. Kekokohan (tahan terhadap masukan sewenang-wenang dan gangguan permintaan perubahan)

Aku mendukung rekomendasi untuk "kode bersih" paman bob. tetapi Anda mungkin ingin melihat http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 karena saya pikir ini berkaitan dengan pertanyaan spesifik Anda sedikit lebih baik. kode yang baik harus melompat dari halaman dan memberi tahu Anda apa fungsinya / cara kerjanya.

Jeff Atwood menulis artikel yang bagus tentang bagaimana pengkode adalah referensi pertama Pengetik: http://www.codinghorror.com/blog/archives/001188.html

Saat menjadi juru ketik Anda harus selalu elegan dalam bekerja, memiliki “tata bahasa” yang tegas dan tepat sangatlah penting. Sekarang mengubah ini menjadi "pemrograman" -typing akan menangkap hasil yang sama.

Struktur

Komentar

Wilayah

Saya seorang insinyur perangkat lunak yang berarti selama pendidikan saya, saya telah menemukan banyak bahasa berbeda tetapi pemrograman saya selalu "terasa" sama, seperti yang saya tulis di fekberg.wordpress.com, saya memiliki cara "khusus" untuk mengetik.

Sekarang pemrograman aplikasi yang berbeda dan dalam bahasa yang berbeda, seperti Java, C #, Assembler, C ++, C saya sudah sampai pada "standar" penulisan yang saya suka.

Saya melihat semuanya sebagai "kotak" atau wilayah dan setiap wilayah memiliki komentar penjelasannya. Suatu wilayah mungkin "Orang kelas" dan di dalam Wilayah ini saya memiliki beberapa metode untuk properti, yang dapat saya sebut "Metode Akses" atau semacamnya dan setiap properti dan wilayah memiliki penjelasan penjelasannya sendiri.

Ini sangat penting, saya selalu melihat kode yang saya lakukan, sebagai "menjadi bagian dari api", saat membuat struktur API dan keanggunan SANGAT penting.

Pikirkan tentang ini. Baca juga makalah saya Communication issues when adapting outsourcingyang menjelaskan secara kasar, bagaimana kode yang buruk dapat menimbulkan konflik, Enterpretasikan sesuka Anda: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Kode yang baik mudah dimengerti, mudah dirawat, dan mudah ditambahkan. Idealnya, ini juga seefisien mungkin tanpa mengorbankan indikator lain.

Kode yang bagus bagi saya adalah sesuatu yang mudah dipahami namun canggih. Hal-hal yang membuat Anda berkata, "wow, tentu saja, kenapa saya tidak berpikir seperti itu?". Kode yang benar-benar bagus tidak sulit untuk dipahami, itu hanya memecahkan masalah yang ada dengan cara langsung (atau cara rekursif, jika itu lebih sederhana).

Kode yang baik adalah tempat Anda tahu apa yang dilakukan metode dari namanya. Kode buruk adalah di mana Anda harus mencari tahu apa fungsi kode itu, untuk memahami namanya.

Kode yang baik adalah di mana jika Anda membacanya, Anda dapat memahami apa yang dilakukannya dalam waktu tidak lebih dari yang dibutuhkan untuk membacanya. Kode buruk adalah di mana Anda akhirnya melihatnya selama berabad-abad mencoba mencari tahu apa yang dilakukannya.

Kode yang baik memiliki nama yang sedemikian rupa sehingga membuat komentar sepele tidak diperlukan.

Kode yang baik cenderung pendek.

Kode yang baik dapat digunakan kembali untuk melakukan apa yang dilakukannya di tempat lain, karena ia tidak bergantung pada hal-hal yang benar-benar tidak berhubungan dengan tujuannya.

Kode yang baik biasanya merupakan seperangkat alat sederhana untuk melakukan pekerjaan sederhana (disatukan dengan cara yang terorganisir dengan baik untuk melakukan pekerjaan yang lebih canggih). Kode buruk cenderung menjadi alat multiguna besar yang mudah rusak dan sulit digunakan.

Kode adalah cerminan dari keterampilan dan pola pikir programmer. Pemrogram yang baik selalu memperhatikan masa depan - bagaimana kode akan berfungsi ketika persyaratan atau keadaan tidak persis seperti sekarang ini. Bagaimana skalabalnya? Betapa nyamannya jika saya bukan orang yang memelihara kode ini? Seberapa dapat digunakan kembali kode tersebut, sehingga orang lain yang melakukan hal serupa dapat menggunakan kembali kode tersebut dan tidak menulisnya lagi. Bagaimana ketika orang lain mencoba memahami kode yang telah saya tulis.

Ketika seorang programmer memiliki pola pikir itu, semua hal lainnya akan berjalan dengan baik.

Catatan: Basis kode dikerjakan oleh banyak pemrogram seiring waktu dan biasanya tidak ada sebutan khusus basis kode untuk pemrogram. Oleh karena itu, kode etik yang baik merupakan cerminan dari semua standar perusahaan dan kualitas tenaga kerja mereka.

(Saya menggunakan "dia" di bawah karena inilah orang yang saya cita-citakan - , terkadang dengan sukses).

Saya percaya bahwa inti dari filosofi programmer yang baik adalah dia selalu berpikir "Saya membuat kode untuk diri saya sendiri di masa depan ketika saya akan melupakan semua tugas ini, mengapa saya mengerjakannya, apa saja risikonya dan bahkan bagaimana ini kode seharusnya berfungsi. "

Karena itu, kodenya harus:

1. Bekerja (tidak peduli seberapa cepat kode mendapatkan jawaban yang salah. Tidak ada kredit parsial di dunia nyata).
2. Jelaskan bagaimana dia tahu bahwa kode ini bekerja. Ini adalah kombinasi dari dokumentasi (javadoc adalah alat pilihan saya), penanganan pengecualian dan kode pengujian. Dalam arti yang sangat nyata, saya percaya bahwa, baris demi baris, kode uji lebih berharga daripada kode fungsional jika tidak ada alasan lain selain menjelaskan "kode ini berfungsi, begitulah seharusnya digunakan, dan inilah mengapa saya harus dibayar. "
3. Dipertahankan. Kode mati adalah mimpi buruk. Pemeliharaan kode warisan adalah pekerjaan rumah tetapi harus dilakukan (dan ingat, ini "warisan" saat meninggalkan meja Anda).

Di sisi lain, saya percaya bahwa programmer yang baik tidak boleh melakukan hal-hal ini:

1. Terobsesi pada pemformatan. Ada banyak IDE, editor, dan printer cantik yang dapat memformat kode sesuai dengan standar atau preferensi pribadi yang Anda rasa sesuai. Saya menggunakan Netbeans, saya mengatur opsi format sekali dan menekan alt-shift-F sesekali. Tentukan tampilan kode yang Anda inginkan, siapkan lingkungan Anda, dan biarkan alat yang bekerja.
2. Terobsesi pada konvensi penamaan dengan mengorbankan komunikasi manusia. Jika konvensi penamaan mengarahkan Anda ke jalan penamaan kelas Anda "IEl elephantProviderSupportAbstractManagerSupport" daripada "Zookeeper", ubah standar sebelum mempersulit orang berikutnya.
3. Lupakan bahwa dia bekerja sebagai tim dengan manusia yang sebenarnya.
4. Lupakan bahwa sumber utama kesalahan pengkodean ada di keyboardnya sekarang. Jika ada kesalahan atau kesalahan, dia harus melihat ke dirinya sendiri dulu.
5. Lupakan bahwa apa yang terjadi akan datang. Pekerjaan apa pun yang dia lakukan sekarang untuk membuat kodenya lebih mudah diakses oleh pembaca di masa mendatang hampir pasti akan menguntungkannya secara langsung (karena siapa yang akan menjadi orang pertama yang diminta untuk melihat kodenya? Dia).

1. Berhasil
2. Ini memiliki tes unit yang membuktikan bahwa itu berfungsi

Sisanya adalah lapisan gula ...

• Kode terbaik memiliki keanggunan tertentu yang Anda kenali segera setelah Anda melihatnya.
• Itu terlihat dibuat, dengan hati-hati dan perhatian terhadap detail. Ini jelas diproduksi dengan seseorang yang memiliki keahlian dan memiliki seni tentangnya - Anda bisa mengatakan itu terlihat terpahat dan dipoles, daripada kasar dan siap.
• Itu konsisten dan mudah dibaca.
• Ini dipecah menjadi fungsi-fungsi kecil dan sangat kohesif yang masing-masing melakukan satu hal dan melakukannya dengan baik.
• Ini digabungkan secara minimal, yang berarti bahwa ketergantungan sedikit dan dikontrol secara ketat, biasanya oleh ...
• Fungsi dan kelas memiliki ketergantungan pada abstraksi daripada implementasi.

Ironisnya, semakin baik programmer, semakin tidak diperlukan dia karena kode yang dihasilkan lebih dapat dipelihara oleh siapa pun (seperti yang dinyatakan oleh persetujuan umum oleh Eran Galperin).

Pengalaman saya mengatakan sebaliknya juga benar. Semakin buruk programmernya , semakin sulit untuk mempertahankan kodenya, sehingga ia menjadi semakin diperlukan , karena tidak ada jiwa lain yang dapat memahami teka-teki yang dihasilkan.

Saya punya contoh yang bagus:

Baca kode sumber GWT (google web takingit), Anda akan melihat bahwa setiap orang bodoh memahaminya (beberapa buku bahasa Inggris lebih sulit dibaca daripada kode ini).