Apakah kesederhanaan selalu meningkatkan Keterbacaan?

Baru-baru ini, saya mengembangkan seperangkat standar pengkodean untuk perusahaan kami. (Kami adalah tim baru yang bercabang ke dalam bahasa baru untuk perusahaan.)

Pada konsep pertama saya, saya menetapkan tujuan standar pengkodean kami sebagai meningkatkan Keterbacaan, Pemeliharaan, Keandalan, dan Kinerja. (Saya mengabaikan kemampuan menulis, portabilitas, biaya, kompatibilitas dengan standar sebelumnya, dll.)

Salah satu tujuan saya saat menulis dokumen ini adalah mendorong gagasan kesederhanaan kode. Idenya adalah bahwa seharusnya hanya ada satu panggilan fungsi atau operasi per baris. Harapan saya adalah ini akan meningkatkan keterbacaan. Itu ide yang saya bawa dari bahasa kami sebelumnya.

Namun, saya mempertanyakan asumsi di balik dorongan ini:

Apakah kesederhanaan selalu meningkatkan keterbacaan?

Apakah ada kasus di mana penulisan kode sederhana mengurangi keterbacaan?

Seharusnya jelas, tetapi dengan "sederhana", maksud saya bukan "lebih mudah untuk menulis", tetapi lebih sedikit hal yang terjadi per baris.

"Sederhana" adalah kata yang terlalu sering digunakan. "Dapat dibaca" secara menguntungkan dapat didefinisikan sebagai "sederhana untuk dipahami", di mana peningkatan kesederhanaan (ukuran) menurut definisi ini meningkatkan keterbacaan, tetapi saya tidak berpikir ini yang Anda maksud. Saya sudah menulis tentang ini di tempat lain , tetapi secara umum sesuatu dapat disebut "lebih sederhana" baik dengan menjadi lebih abstrak (dalam hal ini lebih sedikit konsep dapat mengekspresikan lebih banyak fenomena) atau dengan menjadi lebih konkret (dalam hal ini konsep tidak memerlukan banyak latar belakang pengetahuan untuk memahami di tempat pertama). Saya berpendapat bahwa, tergantung pada perspektif, konsep yang lebih abstrak dapat disebut lebih sederhana daripada konsep yang lebih konkret, atau sebaliknya . Ini, meskipun "abstrak" dan "

Saya akan menggunakan sebagai contoh beberapa kode Haskell yang saya tulis beberapa waktu lalu. Saya mengajukan pertanyaan tentang stackoverflow tentang menggunakan Daftar monad untuk menghitung penghitung di mana setiap digit dapat memiliki basis yang berbeda. Solusi akhirnya saya (tidak tahu banyak Haskell) terlihat seperti:

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Salah satu jawaban mengurangi ini menjadi:

count = mapM (enumFromTo 0)

Yang mana di antara ini yang "lebih sederhana" untuk dipahami (yaitu lebih mudah dibaca) bergantung sepenuhnya pada seberapa nyaman pembaca dengan operasi monadik (abstrak) (dan, dalam hal ini, kode bebas poin). Seorang pembaca yang sangat nyaman dengan konsep-konsep abstrak ini akan lebih suka membaca versi (pendek) yang lebih abstrak, sementara orang yang tidak nyaman dengan operasi-operasi tersebut akan lebih suka membaca versi (lama) yang lebih konkret. Tidak ada satu jawaban tentang versi mana yang lebih mudah dibaca yang akan berlaku untuk semua orang.

Jika standar pengkodean Anda adalah tentang "Keterbacaan, Pemeliharaan, Keandalan, dan Kinerja" maka sebutkan saja .

Jangan mencoba dan menentukan cara untuk mencapai hal-hal ini karena akan selalu ada situasi di mana ada contoh yang berlawanan.

Yang perlu Anda meresepkan adalah hal-hal yang akan menyebabkan kode rusak jika tidak ditaati juga. Sifat-sifat gaya tidak akan melanggar kode dan harus menjadi saran (selama mayoritas tim setuju bahwa itu Keterbacaan, sisanya harus menjadi preferensi pengembang (dengan peninjauan kode sehingga tekanan rekan mengingatkan orang bahwa orang lain perlu membaca kode)) .

Lebih sedikit "barang per baris", kesederhanaan, dan keterbacaan bukanlah hal yang sama. Seseorang dapat mengambil algoritma tidak terdokumentasi yang sangat rumit dan kode itu dengan 1 pernyataan per baris, bukan 2, dan itu tidak akan menjadi jauh lebih mudah dibaca.

Lebih sedikit "barang per baris" juga mungkin membutuhkan pengembang dengan monitor besar dan besar untuk melihat blok kode sekarang tersebar lebih vertikal. Atau menyebabkan ketegangan mata karena membaca font yang lebih kecil.

Keterbacaan adalah metriknya sendiri, yang seringkali membutuhkan kompromi di antara beberapa metrik lainnya yang lebih mudah diukur. Pra-konstruksikan semua metrik lainnya, dan kompromi tidak lagi menjadi mungkin, sehingga kode menjadi kurang dapat dibaca.

Selalu? - TIDAK

Ironisnya, mencapai tingkat kesederhanaan yang tepat bisa menjadi tugas yang rumit. Saya pikir kuncinya di moderasi. Kesederhanaan juga bisa di mata yang melihatnya, jadi jika Anda mendapati diri Anda terlalu memikirkannya - tinggalkan saja atau kembali lagi nanti.

Secara pribadi, ketika saya mencoba untuk kembali dan menyederhanakan sesuatu yang saya tulis, saya fokus pada bidang-bidang di mana saya berubah pikiran atau mencoba beberapa hal untuk mendapatkan apa yang saya inginkan. Area-area tersebut biasanya dapat dihaluskan. Kemudian cukup buat beberapa melewati kode untuk membuatnya lebih mudah dibaca tanpa menyebarkan banyak hal sehingga Anda melompati semua tempat untuk mencari tahu apa yang terjadi pada debug.

Jika saya mencari kesederhanaan, saya dapat menulis kode seperti ini:

10000000000000000000000000000000000000000000

Tetapi jika saya ingin keterbacaan, saya akan memilih ini:

1e43

Di sisi lain, 1000jauh lebih mudah dibaca dan sederhana daripada 1e3kecuali Anda bekerja dengan angka dalam notasi ilmiah sepanjang waktu.

Ini adalah contoh degenerasi dari pola yang jauh lebih umum yang dapat Anda temukan hampir di mana saja - membangun sesuatu dari blok yang sangat sederhana dapat dengan cepat menjadi tidak dapat dibaca / tidak efisien / buruk dalam banyak cara yang berbeda. Generalisasi dan penggunaan kembali, di sisi lain, lebih sulit pada awalnya ("Apa e? Apakah mereka bermaksud menulis 1343?" Seseorang mungkin berkata), tetapi dapat banyak membantu dalam jangka panjang.

Belum tentu. Jika Anda memiliki operasi yang kompleks, kompleksitas itu harus pergi ke suatu tempat. Mengurangi jumlah "barang" yang berjalan pada satu baris berarti itu akan mengambil lebih banyak baris, yang sebenarnya dapat merusak pembacaan kode jika itu membuat rutinitas Anda terlalu "tinggi" untuk muat di satu layar.

Kejelasan + Standar + Penggunaan Kembali Kode + Komentar Baik + Desain Bagus dapat meningkatkan keterbacaan .

Kesederhanaan tidak selalu ada di tangan pengembang karena sifat algoritma dan kompleksitas struktur aplikasi saat ini.

Ambil halaman web sederhana yang melakukan tugas-tugas sederhana. Diberikan semacam rutin, tidak mungkin menyederhanakan logika, tetapi Anda dapat membuatnya lebih jelas dengan komentar, menggunakan nama variabel yang bermakna, menuliskannya secara terstruktur, dll.

Apakah kesederhanaan selalu meningkatkan keterbacaan?

Tidak. Saya telah melihat banyak kasus di mana melakukan banyak hal yang lebih sederhana pada satu baris kurang kompleks daripada memiliki banyak baris.

Ada tradeoff antara kode kurang dan kode sederhana.

Secara umum, saya akan merekomendasikan pergi untuk kode yang lebih sederhana kecuali Anda yakin melakukannya dalam beberapa baris lebih baik. Saya lebih suka memiliki kode "terlalu bertele-tele" daripada kode "terlalu rumit".

"Jadikan sesederhana mungkin, tetapi tidak sederhana" - Sebuah ungkapan yang sering dari Albert Einstein

Kesederhanaan meningkatkan segalanya . Untuk nilai kesederhanaan yang berbeda, tentu saja. Apakah lebih sedikit baris kode? Mungkin. Apakah ini executable yang lebih kecil? Mungkin. Apakah ini sesuatu yang perlu disetujui tim Anda? Benar-benar .

Apakah kesederhanaan selalu meningkatkan keterbacaan? Iya nih. Apakah satu pernyataan per baris selalu lebih sederhana? Tidak. Beberapa bahasa memiliki operator ternary, yang, setelah dipahami, lebih sederhana dan lebih mudah dipahami daripada penugasan yang setara jika / selain itu.

Dalam bahasa yang memungkinkan banyak variabel diatur pada satu baris, melakukannya seringkali lebih mudah dan mudah dipahami daripada apa pun yang sederajat.

Contoh lain: ekspresi reguler melakukan banyak hal, biasanya hanya dalam satu baris, dan persamaan tanpa regex seringkali lebih sulit dibaca. / \ d {3} [-] \ d {3} - \ d {4} / paling tidak setara dengan panggilan fungsi dengan setidaknya beberapa komentar, dan lebih mudah dipahami daripada badan fungsi terkait.

Keterbacaan dan kesederhanaan adalah istilah subyektif yang, tergantung pada orang dan konteksnya, biasanya tetapi tidak selalu sejalan.

Istilah yang lebih objektif adalah keringkasan - sesuatu yang pada prinsipnya dapat Anda hitung dengan menghitung karakter, meskipun ada beberapa kelemahan di dalamnya. Keringkasan tampaknya menyiratkan kesederhanaan dan keterbacaan, tetapi ada (setidaknya menurut saya) pengecualian.

Sepotong kode yang lebih panjang (dan bisa dibilang lebih kompleks) bisa lebih mudah dibaca jika lebih baik mengekspresikan maksud. Apakah definisi kesederhanaan Anda peduli dengan niat adalah hal subjektif lainnya - Anda dapat mendefinisikan kompleksitas dalam hal struktur sintaksis dan entropi teori-informasi, misalnya, tanpa referensi sama sekali tentang niat.

Jadi, nama variabel yang lebih panjang yang dipilih dengan baik dapat ...

• Tingkatkan keterbacaan dengan mengekspresikan niat yang lebih baik
• Kurangi keringkasan - karena itu lebih panjang
• Sama sekali tidak berpengaruh pada kesederhanaan sintaksis - struktur sintaksis kode tidak berubah

Demikian pula, saya mungkin menulis if (some_boolean == true). Dibandingkan dengan alternatif yang setara if (some_boolean), ini ...

• Mengurangi keringkasan
• Mengurangi kesederhanaan sintaksis, tetapi
• Dapat meningkatkan keterbacaan dengan mengungkapkan maksud yang lebih baik.

Tentu saja ini akan memicu protes massal - bagi banyak orang, ini juga selalu merusak keterbacaan. Bagi saya, itu sangat tergantung pada sumber boolean - misalnya nama variabel (atau nama metode atau apa pun) mungkin tidak dengan jelas menyatakan bahwa nilainya adalah "nilai kebenaran". Tentu, ifmemberitahu Anda sesuatu, tetapi masih berbau. Tetapi banyak orang akan menyebut saya idiot karena percaya ini.

Yang merupakan bukti lebih lanjut dari subjektivitas keseluruhan, tentu saja.

Anda semua kehilangan beberapa definisi mendasar . Sederhana, dari root sim-plex , berarti satu lipatan . Sederhana berarti melakukan satu hal . Mudah, dari akar kemudahan , berarti berbaring dekat . Mudah berarti dekat . Contoh kode sederhana yang diberikan dalam jawaban lain tidak persis seperti yang ditampilkan.

Ambil tampilan rotsor dari nilai yang sangat besar. Dia mengatakan ini sederhana . Tidak, menurut perkiraan saya, sederhana. Mudah. Sudah dekat untuk mengetik jumlah 0s yang diperlukan.

10000000000000000000000000000000000000000000

Versi yang mudah dibaca adalah sederhana. Itu melakukan satu hal. Ini mengungkapkan angka dengan menjelaskan ukurannya dalam tujuan notasi yang dibangun untuk fungsi ini.

1e43

Bisakah Anda menggambarkan cuplikan kode "sederhana" Aidan sebagai melakukan satu hal? Ini berisi 10 baris kode (tidak termasuk komentar) dan setidaknya 7 blok (seperti yang saya hitung). Jika Anda mengikuti komentar, Anda akan melihat setidaknya ada 4 hal!

count :: [Integer] -> [[Integer]]
count [] = [[]]
count (x:xs) =
  -- get all possible sequences for the remaining digits
  let
    remDigits :: [[Integer]]
    remDigits = count xs
  in
  -- pull out a possible sequence for the remaining digits
  do nextDigits <- remDigits
     -- pull out all possible values for the current digit
     y <- [0..x]
     -- record that "current digit" : "remaining digits" is
     -- a valid output.
     return (y:nextDigits)

Tetapi, salah satu rekomendasi untuk menulis ulang kode ini adalah satu pernyataan. Aidan menyatakan bahwa pembaca harus menjadi atau menjadi terbiasa dengan pernyataan monadik, penunjuk kode bebas, dll. Itu bagus. Konsep-konsep itu tunggal dan independen untuk dipelajari.

count = mapM (enumFromTo 0)

Anda akan menemukan bahwa kode yang benar-benar sederhana lebih mudah dibaca daripada kode yang mudah karena hanya melakukan satu hal. Anda mungkin perlu pergi dan belajar lebih banyak "satu hal" untuk memahami kode sederhana. Tetapi harus selalu lebih mudah dibaca.

Apakah kesederhanaan selalu meningkatkan keterbacaan?

Saya akan mengatakan, mungkin dengan sedikit kontroversi, sama sekali tidak .

Anda bisa memberikan saya sebuah kelas dengan 200 fungsi anggota di antarmuka publiknya, dan itu mungkin antarmuka publik yang paling mudah dibaca secara manusia di luar sana. Mungkin menyenangkan hanya dengan santai membaca kode dan dokumentasinya. Namun, saya tidak akan menyebutnya "sederhana", karena meskipun mudah dibaca, saya harus khawatir dengan bagaimana semua fungsi ini berinteraksi satu sama lain, dan berpotensi mengawasi kasus-kasus rumit yang diakibatkan oleh penyalahgunaan.

Saya lebih suka kelas dengan 20 fungsi anggota yang tidak begitu mudah dibaca hingga 200, karena "keterbacaan" bukan prioritas utama bagi saya dalam hal mencegah kesalahan manusia dan meningkatkan pemeliharaan kode (kemudahan di mana kita bisa mengubahnya, yaitu).

Namun, ini semua akan bergantung pada definisi pribadi kita tentang "kesederhanaan". "Keterbacaan" biasanya tidak bervariasi yang liar di antara kita, kecuali seseorang telah mengakuisisi begitu banyak keahlian dan kelancaran yang mereka anggap regex menjadi sangat "dibaca", misalnya, melupakan kami semua hanya manusia.

Kesederhanaan

Ada suatu masa, dahulu kala, di mana saya berpikir "kesederhanaan" berarti "semudah mungkin dibaca". Jadi saya akan menulis kode C dengan banyak fungsi kenyamanan, mencoba meningkatkan sintaksis dan membuat hal-hal semudah membaca dan menulis mungkin.

Saya merancang perpustakaan yang sangat besar, kaya, tingkat tinggi sebagai hasilnya, mencoba memodelkan fungsi untuk setiap pemikiran manusia: pembantu demi pembantu demi pembantu, semua untuk membentuk kode klien menjadi sintaks yang lebih mudah dibaca. Kode yang saya tulis dulu mungkin yang paling "mudah dibaca", namun itu juga yang paling "tidak dapat dipelihara" dan "kompleks".

Pelat

Namun saya memiliki gairah singkat dengan LISP sekitar pertengahan 90-an (latecomer). Itu mengubah seluruh gagasan saya tentang "kesederhanaan".

LISP bukan bahasa yang paling mudah dibaca. Semoga tidak ada yang berpikir bahwa mengekstraksi CDR dan CARs sambil menjalankan fungsi rekursif dengan sekumpulan kurung bersarang sangat "mudah dibaca".

Namun demikian, setelah berjuang untuk mendapatkan otak saya melilit sintaks aneh bahasa dan cara-cara yang sepenuhnya rekursif dalam melakukan sesuatu, itu secara permanen mengubah ide saya tentang kesederhanaan.

Apa yang saya temukan dengan kode yang saya tulis di LISP adalah bahwa saya tidak lagi membuat kesalahan yang halus lagi, walaupun sulitnya berpikir seperti itu membuat saya membuat kesalahan yang lebih mencolok (tapi itu mudah dikenali dan diperbaiki). Saya tidak salah memahami apa yang dilakukan fungsi dan melewatkan efek samping yang halus dan tidak terduga. Saya hanya memiliki waktu yang lebih mudah secara umum membuat perubahan dan menulis program yang benar.

Setelah LISP, kesederhanaan bagi saya menjadi tentang minimalis, simetri, fleksibilitas, lebih sedikit efek samping, lebih sedikit tetapi lebih banyak fungsi fleksibel yang bergabung bersama dalam berbagai cara yang tak terbatas.

Saya mulai menghargai pola pikir bahwa kode yang paling dapat diandalkan dari semua adalah kode yang tidak ada. Walaupun ini hanya metrik mentah, saya cenderung melihat potensi kode tidak dapat diandalkan berdasarkan kuantitasnya. Mencari kenyamanan sintaksis sepenuhnya dan keterbacaan cenderung meningkatkan kuantitas itu dengan faktor besar.

Minimalisme

Dengan pola pikir LISP tertanam dalam diri saya, saya lebih memilih API minimalis. Saya lebih suka perpustakaan dengan lebih sedikit tetapi lebih dapat diandalkan, fungsi fleksibel yang kurang nyaman dan potensi lebih sulit untuk dibaca daripada yang menawarkan banyak pembantu "nyaman" dan yang mungkin membuat kode mudah "dibaca" tetapi berpotensi tersandung lebih banyak masalah dengan tidak dapat diandalkan dan kejutan yang dihasilkan dari kesalahpahaman apa yang dilakukan salah satu dari ribuan fungsi ini.

Keamanan

Hal lain tentang LISP adalah keamanan. Ini mempromosikan efek samping minimal dan fungsi murni, dan di situlah saya tidak lagi melihat diri saya membuat kesalahan yang halus, meskipun kesulitan membaca dan menulis dalam bahasa itu meningkatkan lebih banyak kesalahan terang-terangan yang bisa saya temukan 10 detik kemudian.

Fungsi murni dan keadaan tidak berubah menjadi lebih disukai bagi saya setiap kali saya mampu membelinya, bahkan jika sintaksisnya:

sword = sharpen(sword)

... sedikit kurang langsung dan terlepas dari pemikiran manusia daripada:

sharpen(sword)

Keterbacaan VS. Kesederhanaan

Sekali lagi, LISP bukan bahasa yang paling "mudah dibaca". Ini dapat mengemas banyak logika menjadi bagian kecil dari kode (mungkin lebih dari satu pemikiran manusia per baris). Saya cenderung lebih suka satu pemikiran manusia per baris untuk "keterbacaan", tetapi itu belum tentu untuk "kesederhanaan".

Dengan definisi "sederhana" seperti ini, terkadang "sederhana" mungkin agak bersaing dengan "mudah dibaca". Ini lebih mempertimbangkan hal-hal dari sudut pandang desain antarmuka.

Antarmuka yang sederhana berarti Anda perlu mempelajari jauh lebih sedikit hal untuk menggunakannya, dan berpotensi memiliki keandalan yang lebih besar dan lebih sedikit Gotcha sebagai hasil dari minimalis. Dokumentasi yang komprehensif tentang subjek mungkin lebih cocok dengan buklet daripada volume buku yang besar. Namun demikian, ini mungkin memerlukan beberapa pekerjaan kasar dan menghasilkan kode yang kurang mudah dibaca.

"Sederhana" bagi saya meningkatkan kemampuan kami untuk memahami fungsionalitas dalam sistem kami pada tingkat yang luas. "Dapat dibaca" bagi saya meningkatkan kemampuan kami untuk menghubungkan setiap baris kecil kode ke bahasa alami dan pemikiran dan mungkin mempercepat pemahaman kita tentang apa yang dilakukan satu baris kode, terutama jika kita tidak fasih dalam bahasa tersebut.

Regex adalah contoh dari apa yang saya anggap "sangat sederhana". Ini "terlalu sederhana dan tidak dapat dibaca" untuk selera pribadi saya. Ada tindakan penyeimbang bagi saya di antara yang ekstrem ini, namun regex memang memiliki kualitas kesederhanaan seperti LISP seperti yang saya definisikan: minimalisme, simetri, fleksibilitas luar biasa, keandalan, dll. Masalah bagi saya dengan regex adalah bahwa sangat sederhana telah menjadi begitu tidak terbaca ke titik di mana saya tidak berpikir saya akan menjadi lancar dalam hal itu (otak saya tidak berfungsi seperti itu dan saya iri pada orang-orang yang dapat menulis kode regex dengan lancar).

Jadi, itulah definisi saya tentang "kesederhanaan", dan itu sepenuhnya independen dari "keterbacaan" dan kadang-kadang bahkan mengganggu yang lain, yang mengarah ke tindakan penyeimbangan antara perpustakaan yang "lebih nyaman secara sintaksis" dan mudah dibaca tetapi lebih besar atau "secara sintaksis" perpustakaan tidak nyaman ", kurang bisa dibaca, namun lebih kecil. Saya selalu menemukan prioritas "kenyamanan pemahaman" dan "pemeliharaan" yang benar untuk disejajarkan dengan prioritas yang terakhir, dengan preferensi yang kuat terhadap minimalis bahkan dengan biaya yang mudah dibaca dan sintaksis manusia yang lebih alami (tetapi tidak sampai pada titik regex) . YMMV.

Selalu? - IYA NIH

Mencapai tingkat kesederhanaan yang tepat adalah pekerjaan yang rumit dan sulit. Tetapi selalu bermanfaat karena selalu meningkatkan keterbacaan. Saya pikir kuncinya adalah pemahaman yang mendalam. Kesederhanaan adalah absolut, diukur dengan "konsep baru" per "chunk" kode. Beberapa konsep baru berarti lebih sederhana.

Fokus pada area di mana ada sekelompok konsep yang padat dan temukan cara untuk "memotong" atau "meringkas" atau "abstrak". Buat beberapa melewati kode untuk membuatnya lebih sederhana dan lebih mudah dibaca.

Abstraksi yang baik layak untuk ditimbang dengan emas. Abstraksi yang baik membuat ini lebih mudah - dan akibatnya lebih mudah dibaca.

Pertanyaan-pertanyaan mengingatkan saya pada jawaban ini di Stack Overflow, terutama kutipan ini (kualitas pengganti dengan kesederhanaan):

Kualitas - Anda tahu apa itu, tetapi Anda tidak tahu apa itu. Tapi itu kontradiktif dengan diri sendiri. Tetapi beberapa hal lebih baik daripada yang lain, yaitu, mereka memiliki kualitas lebih. Tetapi ketika Anda mencoba untuk mengatakan apa kualitasnya, terlepas dari hal-hal yang memilikinya, semuanya menjadi tidak berguna! Tidak ada yang perlu dibicarakan. Tetapi jika Anda tidak dapat mengatakan apa itu Kualitas, bagaimana Anda tahu apa itu Kualitas, atau bagaimana Anda tahu bahwa Kualitas itu ada? Jika tidak ada yang tahu apa itu, maka untuk semua tujuan praktis itu tidak ada sama sekali. Tetapi untuk semua tujuan praktis itu benar-benar ada. Apa lagi nilai berdasarkan? Mengapa lagi orang membayar kekayaan untuk beberapa hal dan melemparkan yang lain ke tumpukan sampah? Jelas beberapa hal lebih baik daripada yang lain - tetapi apa artinya '' kepahitan ''? - Jadi berputar-putar kamu pergi, memutar roda mental dan tidak menemukan tempat untuk mendapatkan traksi. Apa itu Kualitas? Apa itu?

Saya pikir itu penting bahwa Anda perlu diingat bahwa standar pengkodean terkodifikasi untuk semua manfaatnya tidak akan membuat programmer yang baik dari yang buruk. Sebuah kata seperti 'sederhana' dapat ditafsirkan secara berbeda oleh orang yang berbeda (lihat jawaban Aidan Cully), tetapi itu mungkin bukan hal yang buruk. Pemrogram junior masih perlu kode ditinjau oleh pemrogram senior dan belajar mengapa interpretasi pemrogram senior 'sederhana' lebih baik daripada mereka sendiri.

Satu panggilan fungsi per saluran lebih sederhana? Mari kita coba sebuah contoh!

=== One call per line ===
x = y.getThis()
a = x.getThat()
b = a.getSomethingElse()

=== Less "simple" version ===
b = y.getThis().getThat().getSomethingElse()

Apa yang kamu pikirkan? Apakah satu panggilan per saluran sebenarnya lebih sederhana?