Komentar untuk pertanyaan ini: Memeriksa apakah suatu metode mengembalikan false: menugaskan hasil ke variabel sementara, atau menempatkan pemanggilan metode secara langsung dalam kondisi? mengatakan bahwa Anda harus menggunakannya !boolean
daripada boolean == false
saat menguji kondisi. Mengapa? Bagi saya boolean == false
jauh lebih alami dalam bahasa Inggris dan lebih eksplisit. Saya minta maaf jika ini hanya masalah gaya, tapi saya bertanya-tanya apakah ada alasan lain untuk preferensi ini !boolean
?
60
boolean == true
: itu tidak masuk akal. Ekspresi di dalamif
pernyataan hanyalah: ekspresi. Jika sesuatu sudah mengevaluasi ekspresi boolean, mengapa Anda menambahkan cek untuk memaksanya mengevaluasi itu?!boolean_variable
adalah cara kebanyakan programmer C melakukannya, saya setuju.boolean != true
?Jawaban:
Ketika saya melihat garis seperti
if (!lateForMeeting())
, saya membaca itu sebagai "Jika tidak terlambat untuk bertemu" , yang cukup mudah untuk dipahami, sebagai kebalikan dariif (lateForMeeting() == false)
yang saya baca sebagai "Jika fakta bahwa saya terlambat untuk bertemu adalah salah " .Mereka identik dalam arti, tetapi yang pertama lebih dekat dengan bagaimana kalimat bahasa Inggris yang setara akan dibangun.
sumber
if not late_for_meeting
:)unless late_for_meeting
done()
. Negatif ganda itu buruk.Menulis
== false
dan== true
berlebihan. Itu juga bisa dianggap ekstrem yang sewenang-wenang. Jika Anda mulai menulisLalu mengapa tidak
Atau mengapa tidak
Moral dari cerita ini adalah bahwa jika itu
condition
adalah ekspresi boolean, maka Anda tidak perlu menambahkan== false
; untuk itulah operator!
;)sumber
== false
BUKAN berlebihan, hanya lebih bertele-tele daripada!
. OTOH,== true
berlebihan.(exp1 != exp2)
vs((exp1 == exp2) == false)
. Memang, ini adalah skenario yang dibuat-buat, tetapi tetap saja Anda harus hampir tidak pernah menulis perbandingan eksplisit untuk benar atau salah. Sama seperti Anda harus menggunakan operator!=
, Anda juga harus menggunakannya!
.!
.bool_expression == bool_literal
,== ...
itu mubazir. Apakah Anda menguji benar atau salah tidak relevan. Itu hanya perubahan dalam urutan blok konsekuensi / alternatif. Contoh-contoh Andres menggambarkan hal ini dengan sempurna. Sebagian besar kompiler modern akan mengoptimalkan redundansi, tetapi masih berlebihan.Dalam bahasa C dan beberapa bahasa yang serupa, membandingkan ekspresi boolean untuk kesetaraan dengan
false
atautrue
merupakan kebiasaan berbahaya.Dalam C, ekspresi skalar apa saja (angka atau penunjuk) dapat digunakan dalam konteks boolean, misalnya sebagai kondisi
if
pernyataan. C aturan adalah bahwaif (cond)
setara denganif (cond != 0)
- yaitu, nol adalah palsu, dan setiap nilai bukan nol benar. Jikacond
tipe pointer,0
diperlakukan sebagai konstanta pointer nol;if (ptr)
berartiif (ptr != NULL)
.Ini artinya
dan
tidak berarti hal yang sama . Yang pertama benar jika
cond
tidak nol; yang kedua adalah benar hanya jika itu sama dengantrue
, yang di C (jika Anda punya#include <stdbool.h>
) sederhana1
.Misalnya,
isdigit()
fungsi yang dideklarasikan dalam<ctype.h>
mengembalikanint
nilai,0
jika argumennya adalah digit, bukan nol jika bukan. Dapat kembali42
untuk menunjukkan bahwa kondisinya benar. Membandingkan42 == true
akan gagal.Kebetulan
0
satu-satunya nilai yang dianggap salah, jadi perbandingan kesetaraan denganfalse
akan berhasil;if (!cond)
danif (cond == false)
melakukan hal yang sama. Tetapi jika Anda akan mengambil keuntungan dari itu, Anda harus ingat bahwa membandingkan denganfalse
itu ok, dan membandingkan dengantrue
itu tidak. Lebih buruk lagi, membandingkan dengantrue
akan bekerja sebagian besar waktu (misalnya, operator kesetaraan dan relasional selalu menghasilkan salah satu0
atau1
). Ini berarti bahwa setiap bug yang Anda perkenalkan dengan menggunakan ini masih sulit dilacak. (Jangan khawatir, mereka akan muncul segera setelah Anda demo kode ke klien penting.)C ++ memiliki aturan yang sedikit berbeda; misalnya,
bool
tipenya sedikit lebih terintegrasi ke dalam bahasa, danif (cond)
mengkonversicond
untuk mengetikbool
. Tetapi efeknya (kebanyakan) sama.Beberapa bahasa lain memiliki apa yang orang sebut boolean berperilaku lebih baik, sehingga
cond == true
dancond == false
(atau apa pun sintaks yang terjadi) aman. Meski begitu, setiap bahasa yang saya lihat memilikinot
atau!
operator; itu ada di sana, jadi Anda sebaiknya menggunakannya. Menggunakancond == false
daripada!cond
ataunot cond
tidak, menurut saya, meningkatkan keterbacaan. (Memang benar bahwa!
karakter bisa sulit dilihat sekilas; Saya kadang-kadang menambahkan spasi setelah!
untuk menghindari ini.)Dan seringkali Anda dapat menghindari masalah dan meningkatkan kejelasan dengan mengatur ulang kode sedikit. Misalnya, daripada:
Anda mungkin menulis:
Itu tidak selalu lebih baik, tetapi tidak ada salahnya mencari peluang di tempat itu.
Ringkasan: Dalam C dan C ++, perbandingan kesetaraan dengan
true
danfalse
berbahaya, terlalu bertele-tele, dan gaya yang buruk. Dalam banyak bahasa lain, perbandingan seperti itu mungkin tidak berbahaya, tetapi masih terlalu bertele-tele dan gaya yang buruk.sumber
== true
tidak aman. Terasa lebih baik seperti itu.(==True) . f
untuk memperjelas bahwa kami ingin-> Bool
instantiation dari fungsi kembali-polimorfikf
. Itu lebih jelas daripadanot . not . f
dan kurang canggung daripada(f :: a -> Bool)
.pred(x)==pred(y)
untuk fungsi bool-returnpred
. Alternatif yang akanpred(x)? pred(y) : !pred(y)
Anda setujui hampir tidak dapat diterima.pred(x)
danpred(y)
menggunakan nilai yang sama untuk menunjukkan kebenaran, yang merupakan asumsi aman dalam beberapa bahasa tetapi tidak dalam bahasa lain. Di C, misalnya, Anda mungkin menulis!!pred(x) == !!pred(y)
.Keduanya identik secara fungsional, sehingga yang digunakan adalah masalah selera.
Alasan utama yang saya gunakan
== false
adalah bahwa saya telah menemukan bahwa!
terlalu mudah untuk diabaikan, ketika melihat kode.Karena telah digigit parah oleh ini, saya sudah terbiasa membuatnya sangat jelas ketika menguji palsu.
Seandainya operator dinamai
not
seperti dalam Pascal, saya tidak berpikir ini akan menjadi masalah.sumber
== false
alih-alih!
karena alasan yang sama (untuk membuatnya menonjol). Namun tidak ada persyaratan untuk digunakan== true
, sehingga nilai bukan nol tetap berfungsi sebagaimana mestinya.!
mungkin merupakan kesalahan paling sulit dari jenis ini, ini seharusnya IMO tidak menimbulkan kebiasaan menulis==false
tetapi menulis unit test yang lebih baik.Jika
condition == false
memang "jauh lebih alami dalam bahasa Inggris" untuk Anda maka saya harus berasumsi bahwa Anda bukan penutur asli. Kalau tidak, saya tidak bisa menjelaskan ini, karena tidak ada yang berbicara seperti itu:Bandingkan dengan
Yang mengatakan, saya setuju bahwa karakter tunggal, ramping
!
mudah diabaikan dalam kode. Untuk alasan itu, saya lebih suka kata kuncinot
ketika didukung oleh bahasa. C ++ misalnya memang memungkinkan ini meskipun banyak programmer tidak menyadarinya.Untuk bahasa yang membutuhkan
!
, saya memberi jarak antara operator dan operan. Ini membuat negasi jauh lebih sulit untuk diabaikan:Perhatikan bahwa setiap programmer harus menerjemahkan ini secara otomatis , tanpa berpikir dua kali, untuk "tidak mengkondisikan" di kepala mereka. Memperoleh kelancaran semacam ini dalam membaca idiom kode adalah salah satu langkah pertama untuk menjadi programmer yang baik.
sumber
Ketika saya melihat
var == false
saya selalu bertanya-tanya apakahvar
boolean atau tipe logika dengan lebih dari dua nilai (dengan, misalnya, amaybe
danundefined
dan jugatrue
danfalse
, atau sesuatu seperti nilai sembilan IEEE 1164 ).sumber
karena kadang-kadang Anda mungkin menulis
boolean = false
(dengan kesalahan yang jelas) danfalse == boolean
tidak tampak alami (tidak peduli seberapa bagus praktiknya)sumber
if( INVALID_HANDLE_VALUE == hFile )
untuk menghindari hal-hal seperti itu. Dengan begitu jika Anda tergelincir dan menggunakan satu tanda sama dengan bukan dua, Anda akan mendapatkan kesalahan kompilator. Jelas ini hanya bekerja ketika ekspresi kiri adalah konstan, tetapi itu telah menyelamatkan saya lebih dari sakit kepala daripada yang bisa saya hitung.hFile==INVALID_HANDLE_VALUE
penulisan alami .if (!boolean_variable)
diterjemahkan menjadiif the condition is not true
.if (boolean == false)
diterjemahkan menjadiif the condition not false is true
. Karena itu logika terbalik, lebih sulit untuk dipahami.sumber
isVisible
akan menjadi contoh yang lebih baik. Makaif (!isVisible)
akan berarti jika tidak terlihat - yang lebih sederhana untuk dipahamiif (isVisible==false)
, yang merupakan logika terbalik. Semoga ini lebih jelas sekarang. Atau, apakah saya salah memahami komentar Anda?Dalam kompiler lama (banyak), saya percaya mereka akan memecah (boolean == false) menjadi 2 tugas register dan kode perbandingan dalam bahasa mesin. Contoh pertama akan dipecah menjadi satu tugas dan operator TIDAK. Dalam hal kinerja, operasi perbandingan akan mengambil sejumlah siklus jam, tergantung pada ukuran register yang dibandingkan, dibandingkan dengan pembalikan bitwise (1 jam) dan akan lebih lambat untuk dijalankan.
Yang sedang berkata, saya percaya kompiler baru menghilangkan ini, jadi itu boleh saja untuk pergi dengan baik.
sumber
Di tempat kerja saya sering berurusan dengan Boolean yang bisa nol jadi saya akan sering kode kasus ini sebagai
karena saya pribadi merasakan simetri membuatnya lebih mudah dibaca. Terutama jika ada Boolean lain yang sedang diuji juga.
Saya benar-benar tidak peduli dengan satu atau lain cara.
sumber
value == true
demikian tidak ada alasan untuk memeriksa bahwa itu tidak nol. Jikavalue == null
seharusnya tidak pernah memicu pernyataan if di tempat pertama, makaif (value)
seharusnya sudah cukup.if (value)
melempar pengecualian. Saya akan menghargai jika orang yang downvote memberi alasan.value == true
sudah cukup.Ketika Anda menguji kondisi sebenarnya, masuk akal untuk melakukan hal yang adil
if (condition)
, terutama ketika Anda menerapkan konvensi penamaan variabel boolean dimulai dengan 'is':if (isOpen)
sangat jelas dan menggunakan!= false
akan berlebihan.Untuk C / C ++ / Java / dll. programmer, arti dari '!' Operator sepenuhnya berasimilasi, ke titik yang secara otomatis kita miliki 'tidak' dalam pikiran kita ketika kita melihatnya. Jadi memiliki
if (!isOpen)
sejelasif (_NOT_ isOpen)
bagi saya. Tapi Anda tidak cukup familiar, di C / C ++ Anda bisa membuat makro#define _NOT_ !
. Tapi percayalah, setelah beberapa tahun ini sama sekali tidak perlu.Selain itu, selalu lebih baik untuk menguji nilai boolean tanpa membandingkannya dengan literal. Sebagai contoh, berbahaya untuk menguji
if (x == true)
karena nilai boolean dianggap benar jika bukan nol, dan literal benar hanya memiliki satu nilai spesifik, sehingga x bisa 'benar' (yaitu bukan nol) dan masih perbandingannya bernilai false (karena itu berisi 2 dan literal true adalah, katakanlah, 1.) Tentu saja itu tidak berlaku untuk perbandingan dengan false, tetapi jika Anda tidak menggunakannya saat menguji true, mengapa menggunakannya saat menguji false?sumber
Ukuran diperhitungkan ;)
Dalam ekspresi campuran, lebih mudah dibaca:
Dan terutama untuk ruby contoh di mana ada perbedaan besar:
nol tidak salah, tetapi juga tidak benar.
sumber
Berdasarkan dari pengalaman saya dan jawaban dari pertanyaan saya yang telah Anda tautkan.
Beberapa orang lebih suka menggunakan if (kondisi), karena alasannya lebih pendek untuk menulis. dan bagi saya itu benar-benar masuk akal, misalnya (! isValidated ()) Saya membaca ini sebagai Tidak Divalidasi. tetapi bagi saya itu semua didasarkan pada preferensi pribadi, dan itu tergantung pada struktur logis dari metode isValidated (), apakah itu mengembalikan benar atau salah
sumber
Jika Anda memberi nama variabel dengan benar, maka
!boolean
itu lebih alami. Bunyinyanot boolean
kepada siapa saja yang cukup programmer untuk membaca kode secara mental.sumber
Bagi sebagian orang, semakin cepat suatu makna diungkapkan, semakin baik.
Untuk orang-orang yang memiliki "jika! ..." membandingkan lebih cepat dengan "jika ..." maka harus membaca seluruh kondisi (yang sebenarnya bisa sangat panjang, misalnya (thisThing = thatThing atau sesuatu = hal lain) ATAU ( thinga = thingb dan thinga = thingd), dll.) hanya untuk menemukan == false di akhir.
Memiliki! (Saya benar-benar lebih suka tidak ketika bahasa memungkinkan) tepat di depan mendapat bahasa Inggris 'tidak' untuk kondisi ini di sana lebih cepat.
Masalah ini juga mengarah pada pertimbangan untuk menggunakan
until
dalam bahasa yang mendukungnya, mis. Lakukan 'barang umum' sampai semuanya selesai. Seperti yang orang lain katakan, ekspresi bahasa alami adalah tujuannya. Saya suka contoh "matahari bersinar" di atas.sumber
Alasan lain adalah bahwa jika Anda bekerja dalam basis kode yang menggunakan beberapa bahasa, jika ada satu cara idiomatis untuk melakukan sesuatu yang aman di semua bahasa, itu ide yang cukup bagus untuk melakukannya di mana-mana sehingga Anda membentuk kebiasaan yang baik dan cenderung naik.
Saya tidak dapat memikirkan di mana pun yang
if (!variable)
(atau yang sepadan sepertiif not variable
tergantung pada bahasa Anda) tidak aman, sedangkan misalnyaif self.is_ready() == False: ...
tidak aman dengan python jikaself.is_ready()
kembaliNone
, sekarang atau di masa depan, yang akan menjadi hal yang sangat masuk akal untuk dilakukan terhadap menunjukkan itu tidak siap karenaNone
sama palsuFalse
.sumber