Haruskah saya menggunakan tanda kurung dalam pernyataan logis bahkan di tempat yang tidak perlu?


100

Katakanlah saya memiliki kondisi boolean a AND b OR c AND ddan saya menggunakan bahasa yang ANDmemiliki preseden operasi urutan yang lebih tinggi daripada OR. Saya bisa menulis baris kode ini:

If (a AND b) OR (c AND d) Then ...

Tapi sungguh, itu setara dengan:

If a AND b OR c AND d Then ...

Apakah ada argumen yang mendukung atau menentang termasuk tanda kurung asing? Apakah pengalaman praktis menunjukkan bahwa itu layak termasuk mereka untuk dibaca? Atau itu pertanda bahwa seorang pengembang perlu benar-benar duduk dan menjadi percaya diri dengan dasar-dasar bahasa mereka?


90
Saya mungkin malas, tetapi saya lebih suka memiliki tanda kurung di sebagian besar situasi untuk dibaca.
thorsten müller

6
Saya juga. Saya hanya berharap saya melakukannya lebih untuk keterbacaan dan kurang karena saya terlalu malas untuk menjadi percaya diri / kompeten dalam dasar-dasar bahasa saya.
Jeff Bridgman

16
Penggunaan tanda kurung yang baik seperti penggunaan tata bahasa yang baik. 2 * 3 + 2mungkin sama (2 * 3) + 2tetapi yang kedua lebih mudah dibaca.
Reactgular

16
@Mathew Mungkin jika Anda lemah dalam matematika. Untuk kasus yang lebih kompleks, tentu saja, gunakan tanda kurung. Tetapi untuk yang sangat jelas (BODMAS ...) mereka mengurangi keterbacaan lebih dari membantu karena kekacauan.
Konrad Rudolph

3
Yang mengatakan, prioritas yang sama dari AND / OR berlaku di Basic, Python, SQL ... kesan saya adalah bahwa ini adalah aturan di sebagian besar bahasa modern (walaupun tidak semua).
Tim Goodman

Jawaban:


118

Pengembang yang baik berusaha untuk menulis kode yang jelas dan benar . Mengurung dalam kondisi, bahkan jika mereka tidak benar-benar diperlukan, membantu dengan keduanya.

Untuk kejelasan , pikirkan tanda kurung seperti komentar dalam kode: mereka tidak benar-benar diperlukan, dan secara teori pengembang yang kompeten harus dapat mengetahui kode tanpa mereka. Namun, isyarat ini sangat membantu, karena:

  • Mereka mengurangi pekerjaan yang diperlukan untuk memahami kode.
  • Mereka memberikan konfirmasi maksud pengembang.

Selain itu, tanda kurung tambahan, seperti lekukan, spasi putih, dan standar gaya lainnya, membantu mengatur kode secara visual dengan cara yang logis.

Adapun kebenaran , kondisi tanpa tanda kurung adalah resep untuk kesalahan konyol. Ketika mereka terjadi, mereka bisa menjadi bug yang sulit ditemukan - karena seringkali kondisi yang salah akan berlaku dengan benar sebagian besar waktu, dan hanya kadang-kadang gagal.

Dan bahkan jika Anda melakukannya dengan benar, orang berikutnya yang mengerjakan kode Anda mungkin tidak, baik menambahkan kesalahan pada ekspresi atau salah memahami logika Anda dan dengan demikian menambahkan kesalahan di tempat lain (seperti yang ditunjukkan LarsH dengan benar).

Saya selalu menggunakan tanda kurung untuk ekspresi yang menggabungkan anddan or(dan juga untuk operasi aritmatika dengan masalah prioritas yang serupa).


3
Meskipun, saya pernah mendengarnya mengatakan komentar adalah permintaan maaf (untuk kode yang buruk / sulit dibaca) ... ada kemungkinan Anda bisa menulisnya dengan lebih baik. Saya kira Anda bisa mengatakan hal yang sama tentang tanda kurung.
Jeff Bridgman

6
Aspek lain dari kebenaran adalah melestarikannya melalui perubahan: Meskipun pengembang asli mungkin mendapatkan hak diutamakan tanpa tanda kurung ketika dia pertama kali menulis kode dengan tujuan dan konteks yang segar dalam pikiran, dia (atau yang lain) yang datang kemudian dan tidak mengingat semua detail mungkin mengacaukannya ketika mereka menambahkan lebih banyak istilah untuk ekspresi. (Itu sebagian besar sudah tersirat tapi saya merasa itu layak untuk ditekankan.)
LarsH

1
@ LarsH, terima kasih, saya menambahkan ini secara eksplisit ke jawabannya.

8
+1 "Mereka memberikan konfirmasi maksud pengembang." - programmer mana pun (OK, mungkin tidak semua, tetapi semua yang tinggal di sini ....) dapat mengetahui apa yang akan dilakukan oleh kompiler dengan logika paling kompleks. Sama sekali tidak ada yang bisa mengetahui apa yang dimaksudkan oleh pengembang asli (termasuk dirinya sendiri) beberapa minggu di jalur untuk apa pun di luar yang paling sederhana .....
mattnz

2
Saya pikir @JeffBridgman mereferensikan sudut pandang yang cukup terkenal dari "komentar kadang - kadang bisa menjadi bau kode". Misalnya, lihat ringkasan Jeff Atwood yang mencakup pertanyaan "Bisakah Anda membuat ulang kode sehingga komentar tidak diperlukan?". Saya berpendapat bahwa jika komentar Anda menjelaskan mengapa kode Anda sangat tidak intuitif, itu pasti bisa menjadi petunjuk bahwa ada sesuatu yang salah. Pada saat-saat seperti ini, ada baiknya menyederhanakan kode. Saya sepenuhnya setuju dengan jawaban Anda yang sebenarnya dan mengambil tanda kurung.
Daniel B

94

Itu kurang penting apakah Anda yakin dengan pemahaman bahasa Anda. Yang lebih penting adalah pemahaman bahasa n00b yang mengikuti Anda.

Tulis kode Anda dengan cara yang paling jelas mungkin. Tanda kurung ekstra sering (tetapi tidak selalu) membantu. Menempatkan hanya satu pernyataan pada satu baris sering membantu. Konsistensi dalam gaya pengkodean sering membantu.

Ada yang namanya kurung terlalu banyak, tetapi itu adalah salah satu situasi di mana Anda tidak akan memerlukan nasihat - Anda akan mengetahuinya ketika Anda melihatnya. Pada titik refactor kode Anda untuk mengurangi kompleksitas pernyataan daripada menghapus tanda kurung.


72
Jangan lupa bahwa bahkan jika Anda seorang pengembang solo saat sakit, lelah, atau berurusan dengan kode yang Anda tulis tahun lalu; tingkat pemahaman Anda dikurangi menjadi n00b.
Dan Neely

30
There is such a thing as too many parenthesis- Anda jelas bukan lisper;)
paul

18
Itu saran yang buruk: Jangan menulis untuk noobs. Ini akan mengurangi kualitas kode Anda (jauh) karena Anda tidak dapat menggunakan idiom yang mapan yang melampaui dua bab pertama dari buku pemula.
Konrad Rudolph

10
@KonradRudolph: mungkin begitu, tetapi jangan menulis untuk satu-satunya orang yang mengetahui Seni Pemrograman Komputer dari depan ke belakang, atau bersiaplah untuk harus men-debug kode mereka sesudahnya, dan tidak memiliki petunjuk mengapa Anda melakukan hal-hal seperti itu . Kode dibaca lebih banyak daripada yang tertulis.
haylem

15
@dodgethesteamroller: Saya telah melihat terlalu banyak pengembang yang kompeten / dihormati memperkenalkan bug yang didahulukan (setiap orang memiliki hari yang buruk sekarang dan kemudian) yang tetap tidak diperhatikan selama berabad-abad. Untuk pengembang yang baik yang tahu aturan diutamakan, risiko kesalahan / kesalahan ketik yang tidak terdeteksi terlalu tinggi. Untuk orang lain risikonya lebih tinggi. Pengembang terbaik adalah pengembang yang terbiasa mengingat aturan prioritas bahasa, tetapi melupakannya karena terbiasa menggunakan tanda kurung untuk apa pun yang tidak jelas.
Brendan

32

Iya

Anda harus selalu menggunakan tanda kurung ... Anda tidak mengontrol urutan prioritas ... pengembang kompilator tidak. Ini adalah kisah yang terjadi pada saya tentang tidak menggunakan tanda kurung. Ini mempengaruhi ratusan orang selama periode dua minggu.

Alasan Dunia Nyata

Saya mewarisi aplikasi bingkai utama. Suatu hari, tiba-tiba ia berhenti bekerja. Itu saja ... puf itu baru saja berhenti.

Pekerjaan saya adalah membuatnya bekerja secepat mungkin. Kode sumber belum dimodifikasi selama dua tahun, tetapi tiba-tiba saja berhenti. Saya mencoba untuk mengkompilasi kode dan itu rusak pada baris XX. Saya melihat garis XX dan saya tidak tahu apa yang membuat garis XX putus. Saya meminta spesifikasi terperinci untuk aplikasi ini dan tidak ada. Jalur XX bukan pelakunya.

Saya mencetak kode dan mulai memeriksanya dari atas ke bawah. Saya mulai membuat diagram alur dari apa yang sedang terjadi. Kode itu sangat berbelit-belit sampai saya bahkan tidak bisa memahaminya. Saya menyerah mencoba untuk flowchart itu. Saya takut untuk membuat perubahan tanpa mengetahui bagaimana perubahan itu akan mempengaruhi sisa proses, terutama karena saya tidak punya rincian tentang apa yang dilakukan aplikasi atau di mana itu berada dalam rantai ketergantungan.

Jadi, saya memutuskan untuk mulai di bagian atas kode sumber dan menambahkan whitespce dan rem baris untuk membuat kode lebih mudah dibaca. Saya perhatikan, dalam beberapa kasus, ada jika kondisi yang digabungkan ANDdan ORdan itu tidak jelas dibedakan antara data apa yang sedang ANDdiedit dan data apa yang sedang ORdiedit. Jadi saya mulai meletakkan tanda kurung di sekitar ANDdan ORkondisi untuk membuatnya lebih mudah dibaca.

Saat saya perlahan-lahan membersihkannya, saya secara berkala akan menyelamatkan pekerjaan saya. Pada satu titik saya mencoba mengkompilasi kode dan hal aneh terjadi. Kesalahan telah melompat melewati baris kode asli dan sekarang lebih jauh ke bawah. Jadi saya melanjutkan, melapangkan ANDdan ORmengkondisikan orangtua . Ketika saya selesai membersihkannya, itu berhasil. Go Figure.

Saya kemudian memutuskan untuk mengunjungi toko operasi dan bertanya apakah mereka baru saja memasang komponen baru pada kerangka-utama. Mereka berkata ya, kami baru saja meningkatkan kompiler. Hmmmm.

Ternyata kompiler lama mengevaluasi ekspresi dari kiri ke kanan. Versi baru dari kompiler juga mengevaluasi ekspresi dari kiri ke kanan tetapi kode ambigu, yang berarti kombinasi tidak jelas ANDdan ORtidak dapat diselesaikan.

Pelajaran yang saya pelajari dari ini ... SELALU, SELALU, SELALU menggunakan paren untuk ANDkondisi dan kondisi yang terpisah ORketika mereka digunakan bersama satu sama lain.

Contoh Sederhana

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...(kode berserakan dengan beberapa di antaranya)

Ini adalah versi sederhana dari apa yang saya temui. Ada kondisi lain dengan pernyataan logika gabungan boolean juga.

Saya ingat pernah membawanya ke:
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...



Saya tidak bisa menulis ulang karena tidak ada spesifikasi. Penulis asli sudah lama hilang. Saya ingat tekanan kuat. Seluruh kapal kargo terdampar di pelabuhan dan tidak dapat dimuat karena program kecil ini tidak berfungsi. Tanpa peringatan. Tidak ada perubahan pada kode sumber. Saya baru sadar untuk menanyakan Operasi Jaringan jika mereka memodifikasi apa pun setelah saya perhatikan bahwa menambahkan parens menggeser kesalahan.


22
Itu tampak seperti ilustrasi yang lebih baik mengapa penting untuk memiliki kompiler yang baik.
ruakh

6
@CapeCodGunny: Saya yakin Anda tidak. Tapi masalahnya di sini adalah Anda memiliki vendor compiler buruk yang membuat perubahan besar. Saya tidak melihat bagaimana Anda belajar pelajaran untuk "SELALU, SELALU, SELALU" mengatasi masalah itu, bahkan ketika menggunakan kompiler yang lebih baik.
ruakh

5
@ruakh - Tidak, vendor hanya mengubah parser kode mereka. Saya jadul, saya tidak mengandalkan kemampuan saya untuk mengingat setiap sistem yang saya kodekan atau terlibat. Tanpa dokumentasi semua yang Anda miliki adalah kode sumber. Ketika kode sumber sulit dibaca dan diikuti, ini menciptakan situasi yang sangat menegangkan. Programmer yang tidak menggunakan spasi putih mungkin tidak pernah harus menghadapi situasi seperti yang saya hadapi. Saya juga belajar bahwa menulis kode seperti itu lebih masuk akal: Lihat Dick; Lihat Jane; Lihat Dick AND Jane; Pernyataan sederhana yang mudah dibaca ... komentar ... dan ikuti.
Michael Riley - AKA Gunny

2
Kisah yang hebat, tetapi saya setuju bahwa itu bukan alasan untuk menggunakan tanda kurung. dan / atau diutamakan hampir universal dan tentang hal yang paling tidak mungkin berubah yang bisa dipikirkan orang. Jika Anda tidak dapat mengandalkan perilaku yang konsisten untuk operasi standar dan dasar seperti itu, kompiler Anda adalah sampah dan Anda disemprot apa pun yang Anda lakukan. Cerita Anda adalah 100% masalah kompilator dan 0% masalah kode. Terutama mengingat bahwa perilaku default adalah evaluasi dari kiri ke kanan sederhana - pesanan akan selalu jelas, jadi mengapa ada orang yang menggunakan tanda kurung?

7
Saya pikir ada pelajaran yang dipelajari di sini di kedua sisi ... Anda jauh lebih baik menggunakan tanda kurung terutama ketika alternatifnya bergantung pada perilaku tidak terdokumentasi dari kompiler sehubungan dengan kode yang ambigu . Dan jika pemrogram tidak tahu ekspresi mana yang ambigu, lebih baik gunakan parens. Di sisi lain, berbahaya untuk mengubah perilaku kompiler, tetapi setidaknya itu menimbulkan kesalahan jika perilaku berubah. Akan lebih buruk jika kompiler tidak melakukan kesalahan, tetapi mulai mengkompilasi secara berbeda. Kesalahan melindungi Anda dari bug yang tidak diketahui.
LarsH

18

Ya, jika ada campuran 'dan' dan 'atau'.

Juga ide yang bagus untuk () apa yang secara logis satu cek.

Meskipun yang terbaik adalah dengan menggunakan fungsi predikat yang telah disebut dan mengusir sebagian besar pemeriksaan dan kondisi di sana, meninggalkan jika sederhana dan dapat dibaca.


6
Benar, ada peluang yang sangat baik a AND bmungkin harus diganti dengan fungsi atau nilai boolen yang dihitung sebelumnya yang memiliki nama yang lebih deskriptif.
Jeff Bridgman

14

Tanda kurung secara semantis redundan, jadi kompilernya tidak peduli, tapi itu herring merah - perhatian sebenarnya adalah keterbacaan dan pemahaman programmer.

Saya akan mengambil posisi radikal di sini dan memberikan tanda "tidak" pada tanda kurung a AND b OR c AND d. Setiap pemrogram harus mengingat dengan hati-hati bahwa prioritas dalam ekspresi Boolean TIDAK> DAN> ATAU , seperti halnya mengingat Harap Maafkan Bibi Sally yang Terhormat untuk ekspresi aljabar. Tanda baca yang berlebihan hanya menambah kekacauan visual sebagian besar waktu dalam kode tanpa manfaat dalam keterbacaan programmer.

Juga, jika Anda selalu menggunakan tanda kurung dalam ekspresi logis dan aljabar, maka Anda melepaskan kemampuan untuk menggunakannya sebagai penanda untuk "sesuatu yang rumit sedang terjadi di sini - lihatlah!" Yaitu, dalam kasus di mana Anda ingin menimpa prioritas awal dan memiliki tambahan yang dievaluasi sebelum perkalian, atau ATAU sebelum DAN, tanda kurung adalah bendera merah yang bagus untuk programmer berikutnya. Terlalu banyak menggunakan mereka ketika mereka tidak dibutuhkan, dan Anda menjadi Boy Who Cried Wolf.

Saya akan membuat pengecualian untuk apa pun di luar bidang aljabar (Boolean atau tidak), seperti ekspresi pointer di C, di mana sesuatu yang lebih rumit daripada idiom standar seperti *p++atau p = p->nextmungkin harus dipasangkan untuk menjaga dereferencing dan aritmatika tetap lurus. Dan, tentu saja tidak ada yang berlaku untuk bahasa seperti Lisp, Forth, atau Smalltalk yang menggunakan beberapa bentuk notasi Polandia untuk ekspresi; tetapi untuk sebagian besar bahasa umum, prioritas logis dan aritmatika sepenuhnya standar.


1
+1, tanda kurung untuk kejelasan baik-baik saja, tetapi ANDvs ORadalah kasus yang cukup mendasar yang saya ingin tahu devs lain di tim saya tahu. Saya khawatir bahwa kadang-kadang "menggunakan tanda kurung untuk kejelasan" benar-benar "menggunakan tanda kurung jadi saya tidak perlu repot-repot untuk mempelajari prioritasnya".
Tim Goodman

1
Dalam semua bahasa yang saya bekerja dengan teratur itu .membersebelum operator unary, unary sebelum operator biner, *dan /sebelum +dan -sebelum <dan >dan ==sebelum &&sebelum ||sebelum tugas. Aturan-aturan yang mudah diingat karena mereka cocok "akal sehat" saya tentang bagaimana operator biasanya digunakan (misalnya, Anda tidak akan memberikan ==diutamakan lebih besar dari +atau 1 + 1 == 2berhenti bekerja), dan mereka menutupi 95% dari pertanyaan didahulukan aku harus .
Tim Goodman

4
@TimGoodman Ya, tepat sekali, untuk kedua komentar Anda. Responden lain di sini tampaknya berpikir itu adalah pertanyaan hitam atau putih - baik menggunakan tanda kurung sepanjang waktu, tanpa pengecualian, atau terbang dengan sembarangan di kursi celana Anda melalui lautan aturan yang sewenang-wenang dan tidak mungkin untuk diingat, kode Anda mendidih dengan potensi bug yang sulit ditemukan. (Metafora campuran sangat disengaja.) Jelas cara yang benar adalah moderasi; kejelasan kode itu penting, tetapi begitu juga mengetahui alat Anda dengan baik, dan Anda harus dapat mengharapkan pemahaman minimum tertentu tentang pemrograman dan prinsip-prinsip CS dari rekan tim Anda.
dodgethesteamroller

8

Seperti yang saya lihat:

YA Pro:

  • Urutan operasi eksplisit.
  • Melindungi Anda dari pengembang di masa depan yang tidak memahami urutan operasi.

YA Kontra:

  • Dapat mengakibatkan kode yang berantakan dan sulit dibaca

TIDAK ADA Pro:

  • ?

TIDAK ADA Kekurangan:

  • Urutan operasi tersirat
  • Kode kurang dapat dipelihara untuk pengembang tanpa pemahaman yang baik tentang urutan operasi.

Kata baik, meskipun saya pikir "Mungkin mengakibatkan kode berantakan, sulit dibaca" agak subjektif.
FrustratedWithFormsDesigner

2
Bagaimana cara membuat semantik kode Anda secara eksplisit membuatnya sulit dibaca?
Mason Wheeler

1
Saya setuju dengan yang lain dalam mempertanyakan "Ya Kontra" Anda. Saya pikir itu hampir selalu sebaliknya.

@Frustrated Sebagai subjektif sebagai klaim yang berlawanan. Artinya, tidak sama sekali, sungguh. Sulit diukur.
Konrad Rudolph

1
@MasonWheeler: Walaupun saya setuju bahwa parens eksplisit sangat penting dalam banyak kasus, saya dapat melihat bagaimana seseorang bisa berlebihan dalam membuat semantik menjadi eksplisit. Saya menemukan 3 * a^2 + 2 * b^2lebih mudah dibaca daripada (3 * (a^2)) + (2 * (b^2)), karena format dan prioritasnya sudah biasa dan standar. Demikian juga, Anda bisa (menjadi ekstrem) melarang penggunaan fungsi dan makro (atau kompiler!) Untuk membuat semantik kode Anda lebih eksplisit. Jelas saya tidak menganjurkan itu, tetapi saya berharap untuk menjawab pertanyaan Anda tentang mengapa harus ada batasan (keseimbangan) dalam membuat semuanya eksplisit.
LarsH

3

Apakah ada argumen yang mendukung atau menentang termasuk tanda kurung asing? Apakah pengalaman praktis menunjukkan bahwa itu layak termasuk mereka untuk dibaca? Atau itu pertanda bahwa seorang pengembang perlu benar-benar duduk dan menjadi percaya diri dengan dasar-dasar bahasa mereka?

Jika tidak ada orang lain yang harus melihat kode saya lagi, saya tidak berpikir saya akan peduli.

Tapi, dari pengalaman saya:

  • Saya melihat kode saya lagi sesekali (kadang-kadang bertahun - tahun setelah menulisnya)
  • Orang lain terkadang melihat kode saya
    • Atau bahkan harus mengembangkan / memperbaikinya!
  • Baik saya maupun yang lain tidak ingat persis apa yang saya pikirkan ketika menulisnya
  • Menulis kode "minize the character count" yang cryptic menyakitkan keterbacaan

Saya hampir selalu melakukan ini karena saya percaya pada kemampuan saya untuk dengan cepat membaca dan tidak membuat kesalahan kecil lebih banyak dengan orangtua daripada tidak ada yang lain.

Dalam kasus Anda, saya hampir pasti akan melakukan sesuatu seperti:

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

Ya, lebih banyak kode. Ya, saya bisa melakukan operator bool mewah sebagai gantinya. Tidak, saya tidak suka kesempatan ketika membaca kode 1+ tahun di masa depan saya salah membaca operator bool mewah. Bagaimana jika saya menulis kode dalam bahasa yang memiliki prioritas AND / OR yang berbeda dan harus melompat kembali untuk memperbaikinya? Apakah saya akan pergi, "aha! Saya ingat hal kecil yang pintar ini yang saya lakukan! Saya tidak harus memasukkan parens ketika saya menulis ini tahun lalu, hal yang baik saya ingat sekarang!" jika itu terjadi (atau lebih buruk, orang lain yang tidak menyadari kepintaran ini atau dilemparkan ke dalam situasi tipe "fix secepat")?

Memisahkan dengan () membuatnya jauh lebih mudah untuk dengan cepat menelusuri dan memahami nanti ...


7
Jika Anda akan melakukan itu, mengapa tidak ab = a AND b?
Eric

1
Mungkin karena abakan tetap tidak berubah jika tidak a AND b.
Armali

3

Kasus umum

Dalam C #, perkalian dan pembagian memiliki prioritas di atas penambahan dan pengurangan.

Namun, StyleCop, alat yang menerapkan gaya umum di seluruh basis kode dengan tujuan tambahan untuk mengurangi risiko bug yang disebabkan oleh kode yang mungkin tidak cukup jelas, memiliki aturan SA1407 . Aturan ini akan menghasilkan peringatan dengan sepotong kode seperti ini:

var a = 1 + 2 * 3;

Jelas bahwa hasilnya adalah 7dan tidak 9, tetapi tetap saja, StyleCop menyarankan untuk menempatkan tanda kurung:

var a = 1 + (2 * 3);

Kasus khusus Anda

Dalam kasus khusus Anda, ada prioritas AND dibandingkan dengan OR dalam bahasa tertentu yang Anda gunakan.

Ini bukan bagaimana setiap bahasa berperilaku. Banyak orang lain memperlakukan AND dan OR secara setara.

Sebagai pengembang yang sebagian besar bekerja dengan C #, ketika saya melihat pertanyaan Anda pertama kali dan membaca potongan kode tanpa membaca apa yang telah Anda tulis sebelumnya, godaan pertama saya adalah berkomentar bahwa kedua ungkapan itu tidak sama. Semoga, saya sudah membaca seluruh pertanyaan sebelum berkomentar.

Kekhasan ini dan risiko yang mungkin diyakini sebagian pengembang bahwa AND dan OR memiliki prioritas yang sama membuatnya lebih penting untuk menambahkan tanda kurung.

Jangan menulis kode dengan tujuan untuk menunjukkan bahwa Anda cerdas. Tulis kode dengan tujuan keterbacaan, termasuk oleh orang-orang yang mungkin tidak terbiasa dengan setiap aspek bahasa.


1
"Ini sangat tidak biasa": Menurut Stroustrup2013, C ++ 11 tampaknya memiliki prioritas AND dan OR yang berbeda (hlm. 257). Sama dengan Python: docs.python.org/2/reference/expressions.html
Dirk

10
Re: "Setiap bahasa yang saya tahu memperlakukan DAN dan ATAU sama": Saya ragu itu benar. Jika ini benar, maka Anda tidak tahu apa dari sepuluh bahasa yang paling populer (C, Java, C ++, PHP, JavaScript, Python, C #, Perl, SQL, dan Ruby), dan tidak dalam posisi untuk mengomentari apa yang "tidak biasa", apalagi "sangat tidak biasa".
ruakh

1
Saya setuju dengan ruakh dan mencarinya untuk C ++ 11, python, matlab dan java.
Dirk

3
Bahasa di mana AND dan OR adalah operator biner, dan yang tidak memperlakukan AND sebagai memiliki prioritas lebih tinggi dari OR, adalah omong kosong yang otaknya rusak yang pengarangnya adalah orang yang gagal dalam ilmu komputer. Ini berasal dari notasi logika. Halo, apakah "jumlah produk" tidak berarti apa-apa? Bahkan ada notasi boolean yang menggunakan multiplikasi (penjajaran faktor) untuk AND, dan simbol + untuk OR.
Kaz

3
@ruakh Anda baru saja menegaskan maksud saya untuk saya. Karena ada beberapa kasus tepi patologis tidak berarti bahwa Anda tidak boleh belajar presedensi Boolean standar dan menganggapnya berlaku sampai terbukti sebaliknya. Kami tidak berbicara tentang keputusan desain sewenang-wenang di sini; Aljabar Boolean ditemukan jauh sebelum komputer. Juga, tunjukkan spesifikasi Pascal yang sedang Anda bicarakan. Di sini dan di sini menunjukkan DAN sebelum ATAU.
dodgethesteamroller

1

Seperti yang dikatakan semua orang, gunakan tanda kurung setiap kali membuat ekspresi lebih mudah dibaca. Namun jika ekspresi rumit saya sarankan untuk memperkenalkan fungsi baru untuk subekspresi .


0

Atau itu pertanda bahwa seorang pengembang perlu benar-benar duduk dan menjadi percaya diri dengan dasar-dasar bahasa mereka?

Jika Anda benar-benar menggunakan bahasa dalam bentuk tunggal, mungkin. Sekarang ambil semua bahasa yang Anda tahu, dari usia tua hingga yang paling modern, dari dikompilasi untuk scripting ke SQL ke DSL Anda sendiri yang Anda ciptakan bulan lalu.

Apakah Anda ingat aturan prioritas yang tepat untuk masing-masing bahasa ini, tanpa melihat?


1
Dan seperti yang dicatat oleh @Cape Cod Gunny di atas, bahkan jika Anda pikir Anda tahu bahasa dingin, kompiler / run-time mungkin berubah di bawah Anda.
Jordan

0

"Haruskah saya menggunakan tanda kurung dalam pernyataan logis meskipun tidak diperlukan."

Ya, karena dua orang akan merasa terbantu:

  • Programmer berikutnya, yang memiliki pengetahuan, kompetensi atau gaya mungkin berbeda

  • Masa depan Anda yang kembali ke kode ini di kemudian hari!


-1

Kondisional yang kompleks adalah "aljabar boolean", yang Anda tulis dalam beberapa cara yang, yah, membuatnya tampak persis seperti aljabar, dan Anda pasti akan menggunakan parens untuk aljabar , bukan?

Aturan yang sangat berguna adalah negasi:

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

Atau, dalam format yang sedikit lebih jelas:

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

yang benar - benar jelas hanya aljabar ketika dituliskan sebagai:

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

Tetapi kita juga bisa menerapkan pemikiran untuk penyederhanaan dan perluasan aljabar:

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

walaupun dalam kode Anda harus menulis:

(A||C) && (B||C) && (A||D) && (B||D)

atau, dalam format yang sedikit lebih jelas:

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

Pada dasarnya, kondisi masih hanya ekspresi aljabar, dan dengan jelas menggunakan tanda kurung, Anda dapat lebih mudah menerapkan berbagai aturan aljabar yang sudah Anda ketahui untuk ekspresi, termasuk konsep "menyederhanakan atau memperluas rumus ini".


2
Saya tidak yakin Anda benar-benar menjawab pertanyaan, karena Anda mengarahkan jawaban Anda dengan asumsi yang belum tentu benar. Apakah saya akan menggunakan tanda kurung untuk aljabar? Tidak selalu. Jika membantu dengan keterbacaan, maka tentu saja, tetapi orang lain telah menyatakannya di sini. Dan memperluas aljabar matematika ke bentuk lain tidak persis memiliki korespondensi satu-ke-satu dengan pemrograman - bagaimana jika Anda memeriksa status beberapa nilai string?
Derek

Jika aljabar boolean yang sesuai cukup rumit untuk menjamin parens, kondisional Anda mungkin harus menggunakan parens. Jika cukup sederhana untuk tidak menjamin parens, Anda juga tidak perlu, atau tidak seharusnya. Either way, memikirkannya seperti yang Anda lakukan ekspresi matematika mungkin mengklarifikasi masalah ini.
Narfanator

Contoh saya di atas menggunakan dua dan empat boolean. Jika Anda memeriksa status dua atau lebih nilai string, ini memetakan. Setiap cek sesuai dengan satu variabel boolean; terlepas dari apakah cek itu bilangan bulat atau kesetaraan string; string, array atau hash inclusion; ekspresi yang kompleks itu sendiri ... Tidak masalah; yang terpenting adalah Anda memiliki lebih dari satu ukuran benar / salah dalam ekspresi Anda.
Narfanator

2
Hanya nitpicking, tetapi dalam !(A + B) <=> !A + !Bdan -1*(A + B) = -A + -Bseharusnya tidak operator telah membalik dari +ke *dalam ekspresi kedua?
Jeff Bridgman

-1

Saya akan menggunakan tanda kurung bahkan jika itu opsional, mengapa karena membantu untuk lebih memahami bagi semua orang, untuk orang yang menulis kode serta yang siap untuk melihat kode itu. Dalam kasus Anda, bahkan para operator boolean telah mendahului itu mungkin berhasil pada awalnya, tetapi kami tidak dapat mengatakan itu akan membantu Anda dalam setiap kasus. jadi saya lebih suka tanda kurung pengguna dalam kondisi apa pun yang mungkin memerlukannya atau opsional.


-1

Iya. Anda harus menggunakan dalam hal apa pun ketika Anda merasa kode Anda akan lebih jelas. Ingat kode Anda harus cukup jelas sehingga orang lain dapat mengerti tanpa membaca komentar Anda di dalam kode. Jadi itu adalah praktik yang baik untuk menggunakan kurung dan kawat gigi. Juga perlu diingat bahwa itu mungkin tergantung pada praktik khusus perusahaan / tim Anda. Hanya pertahankan satu pendekatan dan jangan campur.

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.