Apakah kesederhanaan selalu meningkatkan Keterbacaan?


32

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.


16
Jika alternatifnya adalah kode "pintar", maka ya ...
Oded

2
ya - per Pisau Cukur Occam - en.wikipedia.org/wiki/Occam%27s_razor
aggietech

17
Cobalah untuk menghindari penggunaan istilah kaku seperti biasa dan tidak pernah. Ini untuk menghindari fokus pada kasus tepi dan sebaliknya fokus pada masalah paling umum yang kita hadapi. Inilah yang menjadi praktik terbaik.
P.Brian.Mackey

sebenarnya, Anda ingin 2 fungsi / operasi per baris. a = badalah satu operasi, b + cadalah operasi kedua, yang berarti a = b + c2 operasi. Chaining 2 fungsi / operator masih dapat dibaca:, foo(bar())atau a = foo().
zzzzBov

2
Juga, jangan terlalu khawatir. Jika Anda mencoba menghilangkan setiap bit subjektivitas dari penjelasan Anda, seperti halnya jika Anda mencoba menentukan setiap detail yang mungkin dari gaya pengkodean dalam sejuta atau lebih aturan, standar Anda akan menjadi terlalu rumit, tidak dapat dibaca, diabaikan dan karenanya tidak ada gunanya.
Steve314

Jawaban:


47

"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.


11
Beberapa pengembang akan maju sampai mereka mengerti dan lebih suka one-liner. Sulit membayangkan pengembang yang mengerti one-liner datang untuk lebih menyukai versi panjang. Oleh karena itu IMO the one-liner jelas lebih baik.
kevin cline

7
@ kevincline - dengan asumsi pengembang bekerja dalam isolasi, saya setuju, versi yang lebih pendek (mungkin) lebih baik. Jika dia bekerja sebagai bagian dari tim, dan tim tidak berada pada level di mana mereka memahami dan lebih suka one-liner, dan mereka semua harus dapat mempertahankan kode, maka versi yang panjang (mungkin) lebih baik dalam keadaan itu .
Aidan Cully

6
Sebagai tandingan: mengingat bahwa Anda adalah Haskeller yang berpengalaman, Anda dapat membaca versi kedua dengan cepat. Versi pertama, di sisi lain, akan membutuhkan membaca dan memahami lebih banyak kode secara signifikan; Anda tidak bisa melakukannya dalam sekejap. Saya pikir itu membuat versi kedua lebih sederhana.
Tikhon Jelvis

6
@ Steve314: mapMcukup idiom, dan enumFromTomelakukan persis seperti yang tertulis di kaleng. Secara umum, saya menemukan bahwa sebenarnya lebih mudah untuk membuat kesalahan off-by-one jika Anda memperluas kode - hanya ada lebih banyak kode untuk membuat kesalahan. Ini terutama terbukti dengan hal-hal seperti untuk loop vs prosedur tingkat tinggi dalam bahasa lain , tapi menurut saya itu adalah prinsip umum.
Tikhon Jelvis

1
@Tikhon - tapi itu tidak berarti membaca kode sebanyak itu, dan kode itu ada di sana. Berarti bisa ada kompromi. Biasanya sangat sepihak dalam mendukung penggunaan fungsi yang ada daripada menciptakan kembali roda, tetapi ada pengecualian. Ini menjadi sangat jelas dalam C ++, dengan beberapa "algoritma" yang lebih sepele di perpustakaan standar - menggunakannya kadang-kadang bisa lebih verbose dan kurang jelas bahwa menulis kode secara langsung.
Steve314

13

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)) .


Itulah tujuan yang saya tuju dan itu adalah objek yang dinyatakan. Kesederhanaan (atau lebih tepatnya, satu fungsi / operasi per baris) tampaknya secara alami mengikuti dari tujuan itu. Saya mencoba memastikan apakah pemahaman saya tidak benar. Saat Anda sedang membangun standar pengkodean, menetapkan seperangkat aturan dan pedoman adalah inti dari latihan ini. Menetapkan aturan dan pedoman yang terlalu kabur tidak berguna. Dengan demikian, jawaban ini benar-benar tidak membantu.
Richard

5
Argumen saya adalah bahwa menetapkan aturan yang terlalu ketat lebih buruk daripada tidak berguna dan sebenarnya berbahaya. Aturan pengaturan seperti satu pernyataan per baris adalah gaya. Ini adalah hal yang pasti TIDAK harus dalam pedoman kode. Ini tidak memberikan manfaat aktual dan dapat merusak keterbacaan dan pemeliharaan jika diterapkan tanpa berpikir.
Martin York

3
+1 (karena saya tidak bisa +10) Kesalahan umum yang saya lihat dengan manajer pemrograman baru adalah mereka mencoba untuk mengkodekan setiap detail terakhir. Standar pengkodean terbaik lebih seperti kue keberuntungan daripada resep.
JohnFx

"Gaya dan standar pengkodean" adalah nama dokumen. Jelas ini bukan standar (seperti dalam "Never use GoTo" atau "Never use ints") tetapi sebuah style. Gaya pemersatu penting untuk keterbacaan dan pemeliharaan.
Richard

1
Panduan Gaya: "Proyek ini menggunakan tab / spasi (pilih satu). Proyek ini menggunakan gaya kurung K & R / Allman / BSD / GNU (pilih satu). Tolong jangan menambahkan spasi kosong di akhir baris. Harap simpan kode rapi dan dapat dibaca. Semuanya akan ditinjau oleh dua anggota tim dan diri Anda sendiri: untuk keterbacaan / pemeliharaan Anda membutuhkan mayoritas 2/3 untuk memeriksa kode, Untuk Keandalan, dan Kinerja yang Anda butuhkan 3/3 (Harap berikan tes yang sesuai untuk membuktikan ). Lebih banyak aturan akan ditambahkan jika ini disalahgunakan :-) "Selesai.
Martin York

7

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.


5

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.


5

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.


Poin Anda tentang "1e3" menjadi kurang dapat dibaca daripada "100" adalah tepat. Faktanya, ini adalah contoh yang bagus tentang bagaimana muatan kognitif memengaruhi keterbacaan. "1e3" membutuhkan membaca 3 karakter, DAN menerjemahkan eksponensial. Membaca "100" membutuhkan membaca 3 karakter, dan tidak ada evaluasi lebih lanjut.
Stephen Gross

Stephen, sebenarnya ketika membaca angka tiga digit seperti 100Anda harus melakukan dua perkalian dan dua tambahan ( 0+10*(0+10*1)). Namun, setelah terbiasa dengan notasi ini, Anda bahkan tidak menyadarinya. Lagi-lagi ini menunjukkan betapa subyektifnya gagasan tentang kesederhanaan.
Rotsor

Menarik. Jadi, secara tegas, "100" membutuhkan 2 perkalian (1 * 100, 0 * 10), dan 2 operasi tambahan. "1e3" membutuhkan satu operasi multiplikasi. Jadi, jika tidak ada konteks kognitif , "100" lebih sulit dibaca daripada "1e3". Tapi! Jika Anda menyertakan pemuatan konteks-switching kognitif, perhitungannya berbeda. Karena kita biasanya membaca bilangan bulat dalam bentuk non-ilmiah, "100" lebih mudah. Tetapi, jika kita menulis aplikasi teknik di mana semua angka dinyatakan dalam notasi ilmiah, formulir "1e3" lebih mudah!
Stephen Gross

2

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.


Kompleksitas tidak dapat direduksi. Kami memiliki "abstraksi" dan "chunking" dan "organisasi" untuk mencoba mengelola kompleksitas. Saya akan berpikir bahwa operasi yang kompleks dapat dijelaskan dalam sejumlah langkah sederhana. Ia bekerja untuk banyak proses fisik dunia nyata: ringkasan, ikhtisar, dll.
S.Lott

1
@ S.Lott: Benar, tetapi cukup menggulir dan mengklik-Ctrl dapat membuat proses "disederhanakan" lebih sulit untuk diikuti. Saya pernah melihat itu terjadi sekali atau dua kali (itu tidak umum tetapi bisa sangat menyebalkan untuk bekerja dengan ketika terlalu jauh).
FrustratedWithFormsDesigner

3
@ S.Lott - masih ada batasan sejauh mana kompleksitas dapat dikurangi. Anda dapat menghilangkan kompleksitas yang tidak perlu, tetapi Anda hanya dapat mengelola (tidak menghilangkan) kompleksitas yang diperlukan - kompleksitas yang melekat dalam persyaratan. Dapat diperdebatkan, mekanisme untuk mengelola kompleksitas juga meningkatkan kompleksitas - beberapa kompleksitas tambahan terlibat dalam memindahkan kompleksitas yang tidak relevan agar dapat mengungkapkan rincian yang relevan dengan lebih baik untuk aspek / masalah / konstruksi tertentu.
Steve314

1
@ S.Lott - Ya, memang benar bahwa Anda dapat mewakili persyaratan apa pun yang Anda inginkan dengan file sumber tanpa kerumitan (benar-benar kosong). Tetapi karena Anda membutuhkan bahasa yang sangat spesifik untuk memenuhi kebutuhan Anda, semua yang Anda lakukan adalah memindahkan persyaratan Anda ke dalam spesifikasi bahasa.
Steve314

1
@ S.Lott - jika Anda mengklaim bahwa Anda dapat memprediksi posisi Jupiter pada Hari Natal tanpa menggunakan apa pun kecuali G=0, saya pikir Anda gila. Jika tidak, Anda kehilangan poin saya. Tentu saja Anda dapat meringkas detail yang tidak relevan, tetapi itu tidak relevan jika persyaratan Anda mengatakan itu relevan. Jika Anda membaca kembali, saya tidak pernah mengklaim bahwa semua kompleksitas diperlukan - hanya beberapa kompleksitas yang melekat dalam persyaratan dan tidak dapat dihilangkan.
Steve314

2

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.


2

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".


1

"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 .


+1 untuk kutipan, tetapi apakah kesederhanaan meningkatkan keterbacaan?
Richard

"Jadikan sesederhana mungkin kemudian sederhanakan" adalah parafrase yang lebih baik karena para insinyur SW lebih rentan terhadap rekayasa.
mattnz

1
Saya berharap orang-orang akan berhenti mengatakan "buat sesederhana mungkin, tetapi tidak sederhana". Tidak bisakah kita setidaknya menggeneralisasi ke MakeAsGoodAsPossibleButNoMoreSo <Hal, Atribut> sebagai petunjuk teknis umum kita yang tidak berguna? (Maaf @Jesse C. Slicer, Anda jauh dari satu-satunya orang yang mengutip ini, jadi Anda tidak benar-benar layak menerima kata-kata kasar lebih dari orang lain).
psr

1

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.


1

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.


1

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.


1

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.


0

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.


Saya tidak dapat menahan diri untuk berpikir bahwa tanda kutip Anda ada di sana karena Anda sadar bahwa "konsep" dan "bongkahan" itu sendiri subjektif. Satu konsep tunggal orang adalah amalgam orang lain dari tiga ide yang berbeda. Sulit untuk memiliki ukuran absolut dan obyektif tentang hal-hal subjektif.
Steve314

@ Steve314: Kutipan menakut-nakuti? Tidak en.wikipedia.org/wiki/Chunking semua tampaknya serupa bahwa mereka menggambarkan penyederhanaan melalui chunking. (Kecuali teknik gitar, itu tampak berbeda.) Kutipan ada di sana karena ada begitu banyak istilah alternatif untuk abstraksi, chunking, meringkas, dll. Jika saya memilih hanya satu objek setiap orang bahwa abstraksi tidak sama dengan chunking. Kutipan ada di sana untuk menekankan bahwa ini entah bagaimana bisa diperdebatkan. Namun. Ini jelas dilakukan sepanjang waktu dan tampaknya merupakan kecenderungan alami manusia.
S.Lott

Yang tidak saya sangkal - chunking dilakukan setiap saat dan merupakan ide yang bagus. Apa yang saya tolak - bahwa ada aturan objektif definitif untuk di mana batas-batas harus berada di antara potongan. Argumen saya mungkin lebih bertele-tele daripada membantu, tapi saya masih ragu "selalu" dalam "selalu meningkatkan keterbacaan".
Steve314

@ Steve314: Kami selalu mengabstraksi, memotong dan meringkas untuk membantu diri kami sendiri memahami berbagai hal. Selalu. Memotong, mengabstraksi, meringkas ("menyederhanakan") adalah sesuatu yang selalu kita lakukan. Kami baru saja melakukannya. Begitulah cara otak kita memahami kenyataan. Penyederhanaan selalu meningkatkan keterbacaan, dan selalu dapat dilakukan.
S.Lott

ya kita lakukan. Saya tidak pernah mengatakan sebaliknya.
Steve314

-2

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.


1
Inilah mengapa saya mendefinisikan kesederhanaan dalam pertanyaan.
Richard

-2

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?


Iya nih. Satu panggilan per saluran lebih sederhana dan lebih mudah bagi saya untuk membaca. Namun, keterbacaan bersifat subyektif. (Juga, ini bahkan tidak mendekati untuk menjawab pertanyaan.)
Richard

Hai Stephen, dapatkah Anda menguraikan bagaimana menurut Anda ini menjawab pertanyaan? Tidak jelas apa yang ingin Anda tunjukkan di sini.

@MarkTrapp Tidak masalah. Pertanyaan awal mengusulkan pendekatan fungsi tunggal per baris. Contoh yang saya posting menunjukkan dua potongan kode yang sama, satu diimplementasikan sebagai fungsi-tunggal-per-baris, yang lainnya sebagai panggilan metode-rantai. Saya pikir panggilan dirantai jauh lebih mudah dibaca: pendek, tanpa variabel sementara yang tidak perlu, dan elegan.
Stephen Gross

Jika Anda harus membuat rantai getter maka kode Anda dirancang khusus
Musim Dingin
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.