it-swarm-id.com

Buat masalah besar dari == benar?

Ada seorang kolega saya yang terus menulis:

if (someBool == true)

Itu membuat saya naik tembok! Haruskah saya membuat masalah besar atau hanya menjatuhkannya?

105
JoelFan

Itu hanya kode yang berlebihan, bukan hidup atau mati. Namun....

Jika itu sering terjadi, itu bisa menjadi masalah dengan bagaimana someBool dinamai. Nama yang bagus bisa membantu menghilangkan kebutuhan untuk ==true

if(IsSomeCondition)

atau

if(hasCondition)

atau

if(somethingExists)

sebagai contoh.

126
Robert Harvey

Ketika aku melihat someBool == true, Saya merasa seperti programmer belum menginternalisasi ide evaluasi, yang merupakan defisiensi yang cukup mendasar.

Namun, perspektif saya condong karena saya menghabiskan beberapa musim panas dalam pemrograman pengajaran di perguruan tinggi untuk anak-anak, yang sering menulis ungkapan seperti ini karena mereka benar-benar tidak menguasai latihan mental dalam mengevaluasi suatu ekspresi. Begitu mereka mengonsep konsep, redundansi menjadi jelas.

Untuk programmer profesional yang kompeten, ini mungkin bukan masalahnya. Ini mungkin hanya kebiasaan buruk yang mereka kembangkan di awal-awal pemrograman dan tidak pernah benar-benar bergetar. Tapi itu masih akan membuatku sedikit takut jika itu adalah hal pertama yang kulihat seseorang lakukan dalam sebuah wawancara.

71
Tim Goodman

Itu membuat saya gila juga, tapi saya akan mengatakan menyebutkan redundansi kepada mereka dengan cara yang konstruktif dan kemudian menjatuhkannya bahkan jika mereka tidak setuju.

Atau Anda dapat mencoba pendekatan ini:
Anda: Bisakah Anda mulai menggunakan konvensi kode berikut untuk mengevaluasi Boolean?

if (someBool==true)&&(true==true) {}

Mereka: Mengapa kita melakukan itu? Paruh kedua dari pernyataan itu berlebihan, itu akan selalu dievaluasi menjadi benar.

Anda: Oleh George, Anda benar. Saya konyol. Mari kita pergi dengan versi tanpa semua redundansi. Bagaimana tentang?

if (someBool) {}
58
JohnFx

Saya pikir, jika sesuatu yang sepele adalah masalah terbesar Anda dengan rekan kerja Anda, Anda harus menganggap diri Anda cukup beruntung.

45
GrandmasterB

Anda pasti harus menghentikan kebiasaan buruk ini. Dengan lembut ...

Sangat mudah untuk lupa menulis tanda sama dengan ganda, mengubah kode menjadi:

if (someBool = true)

Dalam C # misalnya ini hanya akan menghasilkan peringatan, bukan kesalahan. Jadi, kecuali Anda memperlakukan peringatan sebagai kesalahan kode akan berjalan, tetapkan variabel ke true dan selalu masukkan kondisi.

42
Guffa

Saya setuju dengan Anda, tapi saya akan berperan sebagai advokat iblis di sini:


Bergantung pada bahasa dan nama variabel, x == true tepat:

Pertimbangkan situasi berikut dalam bahasa dengan pengetikan statis dan ketik paksaan untuk tipe integral:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

Seseorang yang membaca bagian kode ini mungkin tidak segera menyadari bahwa tindakan yang Diijinkan adalah variabel boolean - itu juga bisa berupa bilangan bulat, mewakili jumlah tindakan yang diizinkan. Jadi dengan menambahkan == true, menjadi jelas bahwa x adalah boolean, dan bukan bilangan bulat yang dipaksa ke boolean:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}
21
Cam

Bagaimana dengan bool yang dapat dibatalkan?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 
15
Steve Wellens

Biasanya, Anda tidak ingin mempermasalahkan konvensi pengkodean kecuali jika konvensi tersebut menghambat proyek secara signifikan. Saya telah melihat banyak argumen yang memanas meningkatkan hal-hal sekecil wilayah kode dan menggarisbawahi.

Yang sedang berkata, saya tidak melihat masalah dengan menambahkan == true ke pernyataan kondisional. Sebenarnya, saya terbiasa menggunakan == false berbeda dengan tanda seru terkemuka saat menguji kondisi negatif. Saya pikir itu lebih mudah dibaca.

Jika ada konvensi yang mapan, saya katakan ikuti saja kecuali ada alasan untuk berubah. Namun, itu tidak benar-benar layak mengangkat masalah besar.

11
Casey

Ack. Saya pria itu. Rasa malu, rasa malu. Begitulah cara saya belajar, dan itulah cara saya "memformat otomatis" di kepala saya. Satu-satunya waktu saya menggunakan sintaks yang disukai Joel adalah ketika variabel bool memiliki awalan kata kerja seperti "is." Saya membutuhkan kata kerja, baik itu "adalah," "bisa," "lakukan," atau saya butuh == untuk memberikan kata kerja "sama dengan." Saya mungkin tidak akan pernah menghentikan kebiasaan itu, jadi saya akan mengerti jika Anda tidak mengatakan 'halo' kepada saya di jalan.

11
Scott Fletcher

ingatkan saya tentang "kode kegilaan boolean", seperti ini

if(someBool == true)
   otherBool = false;
else
   otherBool = true

Dari pada:

 otherBool = !someBool
11

Secara pribadi, saya sangat tidak suka cara mengatakan "tidak" dalam bahasa berbasis C. Tanda seru kecil itu terlalu mudah untuk dilupakan.

Karenanya saya menuliskannya secara lengkap:

if (someCondition == false) {

Setelah membaca itu sebentar, saya juga ingin simetri

if (someCondition == true) {

Jadi anggap itu artefak dari C menggunakan ! bukan not.

8
user1249

Tergantung pada bahasanya, tapi biasanya itu ide yang buruk ...

Dalam C, tidak pernah lakukan ini. Terlalu mudah untuk menemukan situasi di mana nilai yang Anda uji tidak salah (tidak nol), tetapi juga tidak sama dengan nilai tunggal yang didefinisikan sebagai "benar".

Di Ruby, lakukan ini hanya jika Anda benar-benar yakin bahwa Anda ingin gagal dalam segala hal kecuali Boolean benar.

Dalam C++ dan bahasa statis lainnya dengan tipe bool, itu berlebihan, dan dapat menyebabkan kesalahan pemrograman saat Anda salah ketik = dari pada ==, atau kesalahan promosi seperti yang disebutkan dalam komentar.

6
AShelly

Anda pikir itu buruk? Bagaimana tentang:

if(someCondition) {
  return true;
} else {
  return false;
}
5
Sverre Rabbelier

Saya lebih memilih

if (bVal)

atau

if (!bVal)

juga, tetapi saya khawatir bahwa mengungkitnya akan membuat orang kesal, jadi saran saya adalah melupakannya. Maaf!

4
grokus

anda harus memberi tahu dia bahwa dia melakukan kesalahan.

-nya

if (true == someBool) {

}

jika dia pernah lupa satu = dia dalam masalah besar dalam gaya tulisannya.

4
Display Name

Bagaimana tentang

if (x == "true")

MENGAPA IS ITU STRING ?!

3
atfergs

Sebenarnya, jika itu nullable, pengujian untuk x == true akan diperlukan. :)

3
Matt Sherman

Saya menulis kode seperti itu!

Inilah alasannya:

"if bla == true" berbunyi seperti kalimat, sedangkan "jika bla" tidak dalam banyak kasus. Itu hanya terdengar salah, ketika MEMBACA kode aktual.

Juga kompiler memperingatkan tentang tugas di blok if, jadi benar-benar tidak ada bahaya dalam menggunakan == true. (membingungkan dengan =)

Juga apakah orang yang tidak menulis "== true", menggunakannya "! ()" Untuk "== false"? Saya merasa itu sangat jelek. Dan jika Anda menggunakan "== false", itu hanya sangat konsisten untuk juga menggunakan "== true", alih-alih memiliki dua cara berbeda untuk memverifikasi kebenaran.

3
Ronny Brendel

Ingatlah bahwa Anda bekerja sebagai bagian dari tim, jadi Anda harus menyelesaikannya bersama. "Bermain dengan orang lain" masih merupakan sifat kepribadian yang penting bahkan setelah sekolah dasar :)

3
cdkMoose

Secara umum akan menghilangkan '== true', tetapi bahkan tidak ada gunanya membahasnya kecuali Anda memasukkannya ke dalam standar pengkodean tim Anda.

2
FinnNk

Meskipun saya setuju terutama sebagai pengembang C #, saya tidak bisa mengatakan ini selalu terjadi. Misalnya, dalam Javascript, === akan melakukan coalescence tipe. Jadi dengan asumsi var x = lalu:

if(x) --> true

sementara

if (x === true) --> false

Saya kira itu berbeda dari == karena bahkan di JS saya tidak akan menggunakan if (x == true) tetapi hanya sesuatu untuk dipikirkan.

Sentuhan semacam ini pada titik lain yang muncul di kantor saya:

bool b = false;

Dalam C #, bool b; akan cukup dan akan menginisialisasi b ke false. Namun, itu lebih eksplisit untuk menulis baris di atas dan lagi pula harus dihapus oleh kompiler selama optimasi.

Jadi saya kira maksud saya adalah itu tidak selalu begitu jelas apa yang merupakan dan tidak praktik yang baik dan banyak itu bermuara pada preferensi serta fitur bahasa/keanehan.

2
statichippo

Ah ya, tapi bagaimana jika variabelnya nullable? (bool?)

Beberapa bahasa (C #) akan membutuhkan dan memberikan atau membandingkan dengan 'benar'.

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}
2
Jared G

Yang muda tahu aturannya, tapi yang tua tahu pengecualiannya;)

Terbaru C#, jika Anda berurusan dengan null-able bool, maka Anda harus:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

Jika tristate bukan masalah, maka biasanya seharusnya tidak ada alasan untuk membandingkan sesuatu dengan true/True. Namun, dalam Python dan beberapa bahasa lain seperti C/C++ Anda dapat melakukan if pada ekspresi non-bool. Bahasa-bahasa ini memiliki aturan unik untuk menafsirkan bilangan bulat, petunjuk, daftar, dll. Baik benar atau salah. Terkadang Anda tidak menginginkannya. Misalnya, dalam Python snippet:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

Di sini z harus True, tetapi z2 harus False. Sekarang, bahasa Clojure mendekati ini dengan cara lain - di sana fungsi and tidak harus dievaluasi menjadi bool, tetapi if dapat mengatasinya.

Apa pun bahasanya, kapan pun Anda menemukan diri Anda membandingkan sesuatu dengan True atau False, mungkin perlu dikomentari.

2
Job

Pengkodean seperti itu akan menggosok saya dengan cara yang salah sebelumnya juga. Meskipun pengenal contoh Anda dinamai "someBool", menggunakan gaya pengkodean itu secara tidak sengaja pada variabel yang tidak dijamin sebagai boolean dapat memiliki perilaku yang tidak diinginkan. Jika nilai "someBool" tidak sepenuhnya "benar" atau "salah", hasilnya akan salah.

Saya menemukan bug yang sangat halus tahun lalu yang disebabkan oleh gaya pengkodean yang sulit untuk diidentifikasi karena mata seseorang mengabaikan konstruksi tersebut. Anda akan berpikir, "Bagaimana mungkin itu salah?" Hal yang sama berlaku untuk ekspresi yang dipahami dengan baik seperti "(var)" atau "(! Var)", yang Anda baca atau kode mereka tanpa memverifikasi perilaku mereka.

Jadi saya telah memperkenalkan beberapa standar pengkodean untuk mengurangi keberadaan bug seperti itu dalam basis kode dan kemungkinan bug halus seperti itu akan secara tidak sengaja merayap di suatu waktu di masa mendatang.

  1. Semua ekspresi harus dikurung sesuai maksud mereka.
  2. Semua tes boolean harus dinyatakan dalam negatif, seperti "suchBool! = False".

Dengan membersihkan kode yang tidak sesuai dengan gaya baru, saya telah mengidentifikasi dan memperbaiki beberapa contoh bug halus semacam itu.

1
Huperniketes

Harus menggunakan ini sepanjang waktu di ActionScript 2 (diakui sekarang bahasa mati), karena:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

Jadi hampir selalu yang terbaik adalah spesifik.

1
bburbank

Saya setuju. Ini adalah konstruksi yang berlebihan, khususnya dalam bahasa yang diketik dengan kuat.

Untuk menambahkan penyalahgunaan boolean lain, saya telah menemukan konstruksi semacam ini beberapa kali dalam Javascript, (khususnya di beberapa fungsi monster seperti spageti, seperti dalam 100+ baris):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

Tampaknya, karena kurangnya definisi jenis yang ketat dalam bahasa ini, beberapa programmer lebih suka tidak harus bermain-main dengan false|undefined nilai.

1
Tomas Narros

Saya memiliki seorang kolega yang akan memiliki beberapa kode seperti ini:

if(something == true)

Dan kemudian, untuk semacam tes/debugging, dia akan berharap untuk tidak memanggil blok ini sehingga dia akan mengubahnya menjadi:

if(something == true && false)

Dan kemudian sesekali dia akan mengubahnya menjadi:

if(false)

Yang terburuk adalah, jenis debugging ini menular pada saya pada kesempatan dan sangat buruk bagi pengembang lain untuk membaca!

1
ingh.am

Saya akan mengatakan konsistensi adalah raja dalam basis kode. Jadi Anda harus menggunakan style, yaitu kebanyakan digunakan di organisasi Anda. Cobalah untuk menjadikan gaya Anda sebagai bagian dari pedoman pengkodean perusahaan resmi. Jika sudah ada dalam pedoman, ikuti saja.

(Yang dikatakan, itu juga akan sangat mengganggu saya - tetapi mungkin tidak cukup untuk membuat masalah besar dari itu).

0
driis

Saya lebih suka tidak menempatkan ekstra == true, tapi kadang-kadang saya tidak sengaja memasukkannya dan tidak menyadarinya. Orang tersebut mungkin tidak memperhatikan dan menempatkannya secara tidak sengaja. Saya membaca ulang kode saya dan terkadang memperhatikan bahwa saya menempatkan ekstra == true jadi saya menghapusnya == true. Kadang-kadang saya tidak menyadarinya dan dengan senang hati akan menyambut seseorang yang mengatakan bahwa saya meletakkannya secara berlebihan.

0
sange

Coleague milik saya disebut if a loop. Saya hidup untuk menceritakannya.

0

Seseorang dapat mengembangkan kebiasaan ini ketika melakukan banyak pemrograman di WPF. Ini menggunakan banyak bool? variabel (nullable bool) yang harus Anda tulis if (someBool == true) atau if (someBool ?? false)

0
Poma

Mudah-mudahan, Anda menggunakan bahasa yang masuk akal, seperti VB.NET dengan Option Strict On, yang tidak memungkinkan pemaksaan tipe lain untuk Boolean di dalam pernyataan If. Maka tidak perlu menambahkan "== true" (atau "= True" di VB), karena kasus paksaan tidak dapat terjadi. Jika Anda ingin memeriksa bukan nol maka tuliskan itu secara eksplisit (mis., "Jika x <> 0").

0
o. nate

bagaimana tentang:

int j = 1;
for (int i=1; i>=j; i++) ...

Yap, saya sudah melihatnya.

0
Dave

Ini bau kode untuk pengembang pemula. Mereka belum menguasai/menginternalisasi kondisi boolean dan harus secara eksplisit mengevaluasi kondisi benar atau salah.

0
Chuck Conway

Dalam JavaScript, saya lebih suka if(bool) ketika saya memiliki dokumentasi yang cukup menjelaskan apa yang diharapkan metode ini ... tetapi ketika evaluasi true dapat berarti variabel itu ada, sama dengan angka 1 atau boolean benar, ini lebih sulit.

Mengetik dengan kuat di JS juga berarti kurang fleksibel. Panggilan yang sulit. Bahasa yang diketik dengan kuat, berbaring palu. Kalau tidak, tanyakan mengapa dia melakukannya?

Sebenarnya, ada jawaban Anda: tanyakan mengapa. Lalu perbaiki dia.

0
Clint

gunakan itu sebagai kesempatan untuk mengajarinya. dia akan lebih menghormati Anda jika Anda melakukannya. tidakkah Anda ingin seseorang melakukan hal yang sama untuk Anda?

0
Rush Frisby

Penelitian menunjukkan bahwa kode dengan banyak redudansi berkorelasi kuat dengan kesalahan. Inilah makalah menarik tentang masalah ini (peringatan PDF).

0
David Plumpton

Membandingkan boolean sebenarnya dapat menyebabkan masalah besar. Saya baru-baru berlari ke beberapa kode intern yang berbunyi:

if(foo == false && bar == 2) {...}

Sekarang, ini sepertinya cukup mudah, bukan? Sederhanakan ke:

if(!foo && bar == 2) {...}

Salah. Dalam hal ini, urutan operasi menentukan bahwa && dievaluasi terlebih dahulu, artinya ini benar-benar dievaluasi menjadi:

if(foo == (false && bar == 2))

juga dikenal sebagai

if(!foo)

Hal ekstra yang seharusnya kami periksa, bar == 2, benar-benar hilang. Itu sebabnya saya tidak akan pernah menyetujui ulasan kode yang berisi someBool == [true|false].

(Anda dapat melihat bagaimana pernyataan sebaliknya, == true dan ||, juga akan menyebabkan masalah.)

0
tghw

Ya, ini adalah semacam pola pikir programmer. Sepanjang waktu mereka menganggap "jika kondisi" tidak memiliki keberadaan tanpa ekspresi dengan simbol =, <,> ... Saya telah melihat situasi orang benar-benar mendapatkan perjuangan seperti "fungsi kembali"

if (RowsAffected> 0) {return true; } else {return false; }

Programmer perlu melihat kode mereka dari sudut waktu nyata .. :)

0
Krishna Prasad A

Satu masalah di C adalah bahwa ada tradisi menggunakan nilai selain 0 dan 1 untuk boolean.

typedef enum { WHATEVER = 1 << 4 } MyFlags;
if (flags & WHATEVER) {
}

atau bahkan mengandalkan -1 benar.

Masalahnya adalah Anda menulis API:

struct foo { 
  unsigned int bar : 1;
};

void myapi_foo_set_bar(struct foo *foo, int bar) {
   foo->bar = bar;
}

Di sini jika bilah tidak dikanonikalisasi ke 0 atau 1, bilah tersebut tidak akan cocok di bitfield dan rusak:

myapi_foo_set_bar(foo, flags & WHATEVER); /* broken */

Anda dapat menemukan cara-cara lain untuk memecahkan bools non-kanonik, seperti membandingkannya dengan TRUE atau FALSE seperti dalam pertanyaan!

Pokoknya saya datang ke sekitar adalah bahwa sering masuk akal untuk mengkanonisasi bool:

foo->bar = bar != FALSE;

Ini adalah keanehan khusus C, tentu saja.

0
Havoc P

Ya, ini masalah besar karena nama boolean harus mengatakan bahwa itu boolean. Dikatakan jika Anda memiliki kode ini:

bool arrayIsEmpty = array.length == 0;
if (arrayIsEmpty) { ... }

Ini sudah mudah dibaca sehingga Anda tidak perlu == true, bahkan untuk orang atau programmer dengan sedikit rasa evaluasi.

0
tia

Konvensi pemrograman tidak harus "benar" atau "salah". Mereka ada untuk memberikan program struktur yang akrab bagi mereka yang membacanya, sehingga kemungkinan kesalahan akan terlihat lebih jelas - sulit untuk "melihat" masalah jika semuanya sedikit salah memandang Anda.

Yang penting adalah bahwa konvensi didefinisikan dengan jelas dan disepakati oleh semua peserta (bahkan jika perjanjian itu seperti "Saya setuju untuk menggunakan konvensi ini ketika saya bekerja di sini" :), kalau tidak, itu lebih berbahaya daripada kebaikan.

Tentu saja, kasus membandingkan boolean dengan benar adalah salah dan harus dihindari. ;-)

0
Daniel C. Sobral

Saya menulis if (var == false) karena setelah menulis var saya tidak ingin mundur dan menulis! dibelakangnya. Saya juga suka bagaimana == false membuatnya terlihat lebih jelas.

Namun == benar hanya aneh. Saya tidak tahu apakah ada gunanya membuat masalah besar. Saya tidak akan kecuali dia mendorong orang lain untuk menggunakannya atau membuatnya menjadi standar pengkodean.

0
user2528

Anda dapat mencoba mendekati kolega Anda dengan contoh berikut:

if ((x == 3) == true) {
    ...
}

Dia harus mengatakan bahwa == true berlebihan dan harus ditulis ulang sebagai

if (x == 3) {
    ...
}

sejak x == 3 sudah menjadi ekspresi boolean.

Sekarang berikan padanya someBool == true contoh, tetapi sedikit ditulis ulang:

if ((someBool) == true) {
    ...
}

Karena someBool sudah menjadi boolean, dibandingkan dengan contoh sebelumnya, sekarang harus jelas bahwa == true juga berlebihan dalam contoh ini. Dengan demikian, harus ditulis ulang sebagai:

if (someBool) {
    ...
}
0
gablin

Lucu karena saya selalu mengganti kode seperti:

if(foo) {

Dengan:

if(true == foo) {
if(false == foo) {

Tetapi saya mendapatkan kebiasaan ini karena sebagian besar waktu kode saya bekerja dengan tidak memiliki nama variabel yang jelas.

0
mhitza

Ini mungkin membuat sebagian dari uang Anda dalam satu gumpalan.

Kami memiliki metode ekstensi untuk .IsTrue dan .IsFalse untuk tipe bool.

Jadi kami menulis

if (someBool.IsTrue ())

-atau-

if (someBool.IsFalse ())

Ya! Dan saya suka mereka. Ketika membaca kode itu menjadi lebih jelas bagi saya.

0
ElGringoGrande