The Zen of Python itu...
Pernah baca The Zen of Python? kalo belom pernah silakan dicari dulu, dan baca versi inggrisnya, saya disini cuma mau iseng mendeskripsikan apa yang saya pahami, kalo ngga suka, ya sudah jangan dibaca ^_^
Eksplisit adalah lebih baik daripada implisit.
Sederhana adalah lebih baik daripada kompleks.
Kompleks lebih baik daripada rumit.
Flat (datar) lebih baik daripada bersarang.
Jarang lebih baik daripada padat.
Kasus khusus tidak cukup istimewa untuk melanggar aturan.
Kesalahan tidak boleh lewat diam-diam
Dalam menghadapi ambiguitas, tolak godaan untuk menebak.
Harus ada satu - dan sebaiknya hanya satu - cara yang jelas untuk melakukannya.
Jika implementasi mudah untuk dijelaskan, ini mungkin merupakan ide yang bagus.
Eksplisit adalah lebih baik daripada implisit.
Misal saya mau benerin sepeda motor yang mulai ngga enak dipake, saya bilang ke montirnya "Mas, tolong cek karburator, oli sama rem nya", daripada cuma bilang "Mas motor saya tolong benerin dong"
Begitu pula kalo di milis, lebih tertarik untuk membaca& menjawab email yang subjeknya "Apa sih bedanya Linux & Windows", daripada "Mau tanya soal linux & windows"
Sederhana adalah lebih baik daripada kompleks.
Coding yang sederhaha itu lebih mudah untuk di-debug, dicari kesalahan logika-nya (misal), daripada yang njelimet.
Kompleks lebih baik daripada rumit.
Jika memang domain masalah yang dihadapi banyak, kita mesti bisa memilah-milah dan membagi masalah menjadi beberapa masalah yang lebih kecil. Jangan dibikin semua masalah diselesaikan dalam satu solusi.
Flat (datar) lebih baik daripada bersarang.
Itulah kenapa ada yang namanya switch-case , kita akan pusing dibuat oleh if-else yang terlalu banyak.
Jarang lebih baik daripada padat.
Coding yang mepet2, ngga ngasi ruang untuk spasi, membuat source-code sulit untuk dibaca. Berilah komentar sewajarnya, jeda antara fungsi sewajarnya. Biarlah coding optimizer pada compiler/interpreter yang mengurusi soal lainnya
Kasus khusus tidak cukup istimewa untuk melanggar aturan.
Kalo bahasa di benak saya mungkin: Policy (kebijakan), kebijakan pada suatu aplikasi itu ndak boleh di langgar, karena itu adalah hasil dari perumusan solusi berdasarkan domain masalah. klo emang mesti dirubah, seharusnya di analisa lagi domain masalah yang dihadapi. Mungkin domain masalah sudah berkembang (atau pas analisa dulu itu tidak semua masalah diketahui)
Kesalahan tidak boleh lewat diam-diam
Setiap error adalah feddback, seperti halnya saran seorang pembeli bakso ke pembuat bakso, itu adalah kunci dari Kualitas.
Dalam menghadapi ambiguitas, tolak godaan untuk menebak.
Pelajari kembali masalahnya
Harus ada satu - dan sebaiknya hanya satu - cara yang jelas untuk melakukannya.
$obj->beli_bakso_kepasar() , $obj->beli_bakso_keterminal() :
kenapa ngga gini: $obj->kepasar(); $obj->beli_bakso();
satunya: $obj->keterminal(); $obj->beli_bakso();
Jika implementasi mudah untuk dijelaskan, ini mungkin merupakan ide yang bagus.
Ide bagus, belum tentu ide yang sukses.
Komentar
Posting Komentar