Apakah Anda lebih suka keringkasan atau keterbacaan dalam kode Anda? [Tutup]


21

Pintasan bahasa sering dapat digunakan untuk membuat kode lebih ringkas.

Misalnya, operator penyatuan ternary dan null dapat mengurangi jumlah kode, tetapi bisa dibilang merugikan keterbacaan:

Dalam C #:

Person newGuy = new Person();
if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
} else {
    newGuy.Boss = boss;
}

secara fungsional setara dengan:

Person newGuy = new Person();
newGuy.Boss = boss ?? GetDefaultBoss();

tapi jelas lebih banyak verbose.

Di mana Anda menarik garis ketika datang ke keringkasan vs keterbacaan?


3
Ini adalah pertanyaan subyektif, seseorang yang mengimplementasikan sesuatu akan mengatakan caranya masuk akal, seseorang yang membacanya akan mengatakan itu tidak masuk akal dan orang lain yang membacanya akan mengatakan saya mengerti tetapi saya lebih suka cara lain. Ini hanyalah preferensi.
Chris

20
Saya pikir versi kedua lebih mudah dibaca.
Vaibhav

2
Anda membingungkan keringkasan dengan kesederhanaan. Keringkasan meningkatkan keterbacaan. Kesakitan mengurangi itu.
Ferruccio

1
@ ThorbjørnRavnAndersen: Audiens untuk kode C # biasanya "pengembang dengan latar belakang C #". Dari apa yang saya lihat, konsensus di sini di programmer.se tampaknya Anda tidak boleh menghindari menggunakan fitur bahasa yang berguna hanya karena seseorang mungkin tidak terbiasa dengan mereka. (Lihat juga: programmers.stackexchange.com/q/101513/33843. )
Heinzi

1
duplikat ?: programmers.stackexchange.com/q/58630/15464 .. Oh, ini lebih tua. :)
Steven Jeuris

Jawaban:


63

Kedua.

Contoh pertama Anda tentu saja lebih verbose, dan bisa dibilang lebih eksplisit ... tetapi juga mengharuskan saya untuk memindai lima baris, bukan satu. Lebih buruk lagi, itu menekankan tujuannya - memberikan nilai newGuy.Boss.

Contoh kedua Anda mungkin dikenakan biaya satu detik jika saya tidak terbiasa dengan operator penggabungan nol, tetapi tidak ada keraguan mengenai tujuannya, dan jika saya memindai melalui rutin yang lebih besar mencari sumber nilai, itu akan akan lebih mudah bagi saya untuk memilih yang ini.

Sekarang, bandingkan ini:

if (boss == null) {
    newGuy.Boss = GetDefaultBoss();
    newGuy.IsTemp = true;
    newGuy.AddTask("orientation");
} else {
    newGuy.Boss = boss;
    newGuy.IsTemp = false;
}

...dengan:

newGuy.Boss = boss ?? GetDefaultBoss();
newGuy.IsTemp = boss == null;
if ( boss == null ) newGuy.AddTask("orientation");

Contoh terakhir jauh lebih pendek, tetapi sekarang mengaburkan tujuannya dengan membuat tugas yang dipicu oleh tes yang sama tampak berbeda. Di sini, saya merasa verbositas yang pertama dibenarkan.


3
Jawaban yang sangat bagus! - Ini bukan tentang verbositas tetapi tentang tujuannya.
Damovisa

2
@Damovisa: tepatnya - tujuan kode adalah komunikasi, dan tidak ada alasan umum mengapa ini tidak boleh dilakukan sejelas mungkin (tapi tidak lebih).
Shog9

1
Mempelajari operator penggabungan nol akan membutuhkan waktu lebih dari satu detik - tetapi jika Anda tidak mengetahuinya, maka Anda harus mempelajarinya!
Casebash

2
Ah "??" akan menyenangkan di Jawa.

Meskipun contoh terakhir lebih pendek dalam hal kode, itu sebenarnya mengevaluasi boss3 kali dibandingkan dengan hanya satu kali dalam contoh verbose. Ini hanyalah alasan lain mengapa kode pendek hanya demi menjadi lebih pendek adalah ide yang buruk. Saya pikir keringkasan harus menjadi yang kedua dari tujuan utama, apakah itu keterbacaan / pemeliharaan (untuk kode kompleks) atau kinerja (untuk bagian-bagian penting dari loop dalam, dll.). Dengan kata lain, jangan pernah mengoptimalkan secara murni untuk keringkasan - kecuali jika Anda berencana untuk mengirim kode Anda melalui koneksi 1bps;)
user193130

16

Meskipun keduanya adalah tujuan yang baik, saya akan selalu berpihak pada Keterbacaan ketika dipaksa untuk memilih satu.

Saya berpendapat bahwa contoh Anda meningkatkan keterbacaan dan singkatnya. Namun pertimbangkan:

if( a > b )
{
    foo = bar
}
else
{
    if( c.isThing() ){
        foo = somethingElse;
    }
    else{
        foo = someFurtherThing.GetFoo();
    }
}

sebagai lawan

foo = a > b ? bar ?? whatever.something : c.isThing() ? somethingElse : someFurtherThing.GetFoo();

Yang terakhir ini singkat, tetapi sulit dibaca. Yang pertama adalah verbose, tetapi aliran logika jelas.

Pada akhirnya, singkatnya tidak melayani banyak tujuan, selain kemampuan untuk lebih cocok di layar. Keterbacaan membuatnya lebih mudah untuk di-debug, dan oleh karenanya seharusnya lebih disukai.


11
Pemformatan yang tepat dapat dengan mudah meningkatkan keterbacaan contoh kedua. Ini adalah perbandingan yang tidak adil. Ketika diformat seperti ini , saya sama sekali tidak yakin itu seburuk itu.
Steven Jeuris

Sampel kode tidak setara: Yang pertama hilang ?? whatever.something.
John B. Lambe

11

Saya akan mengatakan sebagai aturan umum tidak pernah mengorbankan keterbacaan karena keringkasan, tetapi tidak pernah menilai keterbacaan berdasarkan programmer lain yang kurang pengetahuan tentang hal itu.

Keringkasan dan keterbacaan tidak bertentangan. Seperti jawaban ini, terkadang lebih pendek lebih mudah dibaca.


4
+1 karena tidak mengasumsikan kurangnya pengetahuan programmer lain. Dalam contoh yang diberikan, opsi kedua hanya kurang terbaca jika Anda tidak terbiasa dengan operator penggabungan nol. Saya tidak akan pernah menulis kode saya berdasarkan asumsi bahwa rekan kerja saya tidak tahu sintaks bahasa. Bahkan jika mereka tidak tahu apa ??artinya, jika saya menggunakannya dan kemudian mereka mempelajarinya, kami berdua mendapat manfaat. Dan tidak sulit untuk mengetik "?? operator" di msdn.com
Tim Goodman

4

Saya akan mengatakan saya lebih suka keterbacaan, meskipun itu kadang-kadang berarti menggunakan kode ringkas. (Yaitu ternary untuk kondisional yang relatif sederhana di dalam blok bersyarat yang lebih besar.)

Pada dasarnya, jika itu sulit untuk dimengerti, jangan lakukan itu.


3

Keterbacaan menjadi yang utama ketika bertentangan dengan keringkasan, karena kode dimodifikasi lebih sering daripada yang awalnya ditulis. Di samping itu:

  1. Kebisingan sintaksis dan kode boilerplate sering mengaburkan niat dan dengan demikian merusak keterbacaan. Terkadang kode yang lebih ringkas juga lebih mudah dibaca. Misalnya, pikirkan fungsi lambda atau delegasi / fungsi kelas satu versus kelas metode tunggal yang mengimplementasikan antarmuka metode tunggal.

  2. Keterbacaan harus dinilai berdasarkan seberapa mudah kode dibaca untuk programmer yang cukup berpengalaman yang tahu bahasa dan fitur unik / canggihnya dengan cukup baik, bukan monyet kode yang nyaris tidak kompeten yang hanya mengetahui penyebut umum terendah.


2

Satu aspek yang menurut saya belum disebutkan: apa tujuan Anda ?

Jika semua yang Anda pedulikan adalah keamanan pekerjaan, cari keringkasan & kekompakan atas segalanya. Lewati mengomentari kode Anda juga.

Jika Anda ingin dapat dengan mudah menyerahkan kode Anda kepada orang lain saat Anda mengerjakan proyek baru yang keren, gunakan keterbacaan, kejelasan, dan banyak komentar yang solid.

Catatan: di atas bukan tentang Anda secara pribadi, @Damovisa; itu untuk siapa pun yang memilih antara dua posisi.


Kedengarannya seperti keamanan pekerjaan tetapi jika Anda ingin menjadi seorang programmer, itu adalah keamanan pekerjaan di perusahaan yang salah ...;)
Alois Mahdal

2

Ada satu hal yang dimiliki oleh versi verbose.

Ini memiliki lebih banyak garis, dan sebagian besar pengadu berorientasi pada garis ! Sangat sulit untuk menetapkan break point di tengah ekspresi, tetapi biasanya sepele untuk mengaturnya di dalam pernyataan blok.

Dengan kata lain, yang mana yang ingin Anda lihat di editor Anda jika Anda ingin debugger Anda memulai kapan boss == null?

(Itu bilang aku suka ?? - operator)


0

Keterbacaan harus didahulukan, jangka panjang kebanyakan orang menghabiskan sebagian besar waktu memodifikasi atau memperluas kode yang ada - keterbacaan adalah bagian besar dari kemampuan pemeliharaan.

Yang mengatakan, keringkasan adalah sesuatu yang dapat berkontribusi terhadap keterbacaan. Misalnya, dalam pertanyaan Anda, cuplikan kedua lebih mudah dibaca dan lebih ringkas.

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.