Mana yang lebih bisa dipertahankan - penugasan boolean melalui if / else atau ekspresi boolean?


11

Mana yang akan dianggap lebih dapat dipertahankan?

if (a == b) c = true; else c = false;

atau

 c = (a == b);

Saya sudah mencoba mencari di Kode Lengkap, tetapi tidak dapat menemukan jawaban.

Saya pikir yang pertama lebih mudah dibaca (Anda benar-benar dapat membacanya keras-keras), yang saya pikir membuatnya lebih mudah dikelola. Yang kedua tentu saja lebih masuk akal dan mengurangi kode, tapi saya tidak yakin itu bisa dipertahankan untuk pengembang C # (saya berharap untuk melihat idiom ini lebih dalam, misalnya, Python).


3
Keduanya tidak setara. Anda membutuhkan else c = falseuntuk yang pertama atau membuat penugasan ||=dalam yang kedua.

17
Saya pikir fakta bahwa Anda harus melakukan dua pengeditan pada formulir pertama menjawab pertanyaan Anda!
James

7
Saya setuju dengan @James. Bentuk kedua, meski bukan sebagai verbose, sangat mudah dipahami dan tidak meninggalkan makna ganda. Tidak ada trik atau jalan pintas yang diambil, hanya saja pendek karena konsepnya sederhana. Fakta bahwa Anda mengkodekan yang pertama dengan bug, dan harus mengeditnya untuk memperbaikinya, dan itu masih belum sempurna (penggunaan kawat gigi yang tidak konsisten), adalah bukti positif bahwa itu tidak semudah yang Anda pikirkan.
Eric King

5
Wow, apakah C # devs benar-benar menganggap bentuk pertama dapat diterima? Ini ... benar-benar mengurangi kepercayaan saya pada mereka. Dalam pengalaman saya, penggunaan bentuk pertama sangat mengisyaratkan kesalahpahaman ekspresi boolean.
Andres F.

2
Hanya untuk membuat hal-hal menarik, berikut adalah pilihan lain:c = a==b ? true : false;
FrustratedWithFormsDesigner

Jawaban:


14

Opsi kedua lebih baik.

Ada alasan yang pasti untuk waspada terhadap pintasan pemrograman yang cerdik yang mengganggu pemeliharaan dengan mengaburkan maksud kode. Jadi, saya tidak menyalahkan Anda karena mengajukan pertanyaan.

Namun, saya tidak menganggapnya c = (a == b);sebagai contoh trik cerdas. Ini adalah representasi langsung dari konsep sederhana. Sejujur ​​yang Anda bisa.

Sebuah tepat, "dipelihara" format contoh pertama Anda (tanpa kawat gigi hilang dan satu baris membangun, yang saya lakukan mempertimbangkan jalan pintas pintar) akan menghasilkan kode ini:

if (a == b)
{
    c = true; 
}
else 
{
    c = false;
}

Dalam pengalaman saya, menulis logika boolean sederhana sedemikian verbose, rawan kesalahan adalah tanda kode "rapuh". Ini akan membuat saya bertanya-tanya bagaimana logika yang lebih kompleks sedang ditangani dalam basis kode ini.


15

Pertama, sadari bahwa kedua bentuk Anda tidak setara.

if (a == b) c = true;

cakan disetel ke true jika asama dengan b, dan jika tidak, nilainya akan tetap apa pun yang sudah ada.

c = (a == b);

cakan disetel ke true jika asama dengan b, dan jika tidak, itu akan disetel ke false.

Jika Anda ingin yang setara dengan bentuk kedua, dengan gaya bentuk pertama, Anda perlu menulis seperti ini:

if (a == b) {
  c = true;
} else c = false;

Sekarang sudah jelas mana dari keduanya yang lebih mudah dibaca, lebih dapat dipelihara, dan lebih kecil kemungkinannya untuk memperkenalkan bug jika ada perubahan. Tetap dengan bentuk kedua.


Benar sekali - Saya telah memperbarui pertanyaan saya.
Bret Walker

Saya menganggap bentuk kedua terlalu panjang dan rumit - jika Anda ingin efek itu, gunakan tugas boolean.
Pasang kembali Monica - M. Schröder

11

Saya tidak setuju bahwa formulir pertama Anda lebih mudah dibaca - tentu saja bukan C # yang idiomatis untuk memiliki dua pernyataan pada satu baris, dan tidak disarankan untuk memiliki ifpernyataan tanpa menggunakan kawat gigi.

Kedua, saya tidak melihat bagaimana bentuk kedua kurang bisa dipertahankan - tidak ada yang perlu dipertahankan. Ini adalah pernyataan sederhana tentang hubungan antara adan bdan itu tidak bisa diungkapkan dengan lebih sederhana.

Alasan lain untuk memilih bentuk kedua adalah bahwa Anda dapat mendeklarasikan cdan menetapkannya dalam satu pernyataan yaitu

bool c = (a == b);

Memodifikasi variabel dapat dengan mudah menyebabkan kesalahan, jadi saya akan menghindarinya. Menggunakan ifpernyataan membutuhkan variabel yang harus dideklarasikan sebelum bersyarat dan kemudian dimodifikasi.


Saya membaca dua pernyataan dalam satu baris sebagai kode semu
Jimmy Hoffa

1
+1 untuk " Another reason to prefer the second form is that you can declare c and assign it in a single statement"
Andres F.

0

"lebih bisa dipelihara" bisa sangat subyektif.

Saya biasanya lebih suka keterbacaan dan niat daripada pengurangan kode. Saya pikir Anda menyimpan 8 karakter yang diketik dengan menggunakan formulir dikurangi.

Membawa bahasa dan budaya di sekitar bahasa adalah karakteristik 'keterbacaan' menurut saya.

Ada kalanya kinerja dapat menyebabkan pengurangan kode untuk mengoptimalkan kode byte yang dihasilkan, tetapi itu harus dilakukan dengan hati-hati setelah beberapa profil.


Subyektif: Duh. Pengurangan kode: Dapat juga (jika tidak berlebihan) meningkatkan kejelasan dan mengomunikasikan maksud dengan lebih baik. Kinerja: Tidak ada masalah sama sekali (optimasi terkadang penting, tetapi ini bukan sesuatu yang termasuk dalam optimasi, karena secara praktis tidak pernah berarti - mungkin bahkan tidak jika Anda sedang menulis kernel atau driver).

4
Bentuk pertama memiliki setidaknya 1 bug yang perlu diperbaiki, disembunyikan dalam verbositasnya. Bentuk kedua sederhana dan to the point, dan tidak memiliki bug. Saya mengistirahatkan koper saya. Bagaimanapun, tujuan utamanya bukan untuk mengetikkan lebih sedikit karakter! Dan pertanyaan ini sama sekali bukan tentang kinerja, yang tidak relevan dalam kasus ini.
Andres F.

@nannan tepat maksud saya, Duh. pengurangan kode seseorang adalah kejelasan orang lain. Saya tidak mengutip optimisasi sebagai perhatian utama ... Saya menggunakannya sebagai contoh. Alasan Anda menambahkan trik pintar atau keluar dari norma harus diseimbangkan dengan apa pun yang Anda / budaya / perusahaan anggap dapat dibaca.
Johnnie

1
Menulis ekspresi boolean yang bersih bukanlah trik yang cerdas!
Andres F.

Saya kira saya akan lebih menghargai komentar Anda jika Anda benar-benar membahas semangat pertanyaan dan bukan analogi gila yang digunakan untuk menopang konsep yang mendasarinya.
Johnnie

0

Kedua. Ini memiliki pengulangan kurang (KERING) dan lebih mudah untuk memahami apa yang terjadi, yang cmemegang nilai apakah atau tidak adan bsama.

IMHO, bahkan lebih baik

c = a == b

Sama seperti saya akan menulis

  • 1 + 2 + 3 dari pada ((1 + 2) + 3)
  • 5 + 3 * 7 dari pada (5 + (3 * 7))

Jelas dan sepele kode yang tidak perlu bukanlah suatu kebajikan. Itu berantakan.


-4

Pemilih yang kurang, jelaskan apa yang salah dengan jawaban saya yang telah direvisi.

Ya, c = (a == b);bisa sulit dibaca (lebih buruk lagi, StyleCop mengeluh tentang tanda kurung yang tidak perlu), tapi saya masih suka kesederhanaan a == b. Oleh karena itu, di sini adalah apa yang saya ingin menggunakan ketika kedua adan badalah sama:

private static bool NoPeriod
{
    get
    {
        return this.MyWaveLength == this.HerWaveLength;
    }
}

Dan kemudian Anda dapat melakukan: this.c = this.NoPeriodalih-alih:

this.c = this.MyWavelength == this.HerWaveLength;

1
jadi maksudmu return this.MyWaveLength = this.HerWaveLength;atau return this.MyWaveLength == this.HerWaveLength;sebaliknya?
Jesse C. Slicer

5
Apa!? c = (a == b);tidak rawan kesalahan. Bentuk pertama dalam pertanyaan awal adalah cara yang lebih rentan kesalahan , seperti yang ditunjukkan oleh OP sendiri yang harus mengedit pertanyaannya untuk memperbaiki bug!
Andres F.

Saya kira solusi yang Anda sarankan memiliki bug = vs. ==
Ondra

@Ondra Morský, terima kasih ... kompiler akan menangkap ini untuk saya.
Ayub

6
Saya tidak terbiasa dengan StyleCop, tetapi jika memberitahu Anda tanda kurung yang tidak perlu itu buruk, Anda harus mematikannya. Tanda kurung yang tidak perlu tidak diperlukan untuk kompiler, tetapi mereka bisa sangat, sangat bagus untuk mata manusia. Jika Anda menulis c = a == b; kompiler dapat menemukannya dengan baik, tetapi lebih sulit bagi manusia.
Michael Shaw
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.