Buat masalah besar dari == benar?


105

Ada seorang kolega saya yang terus menulis:

if (someBool == true)

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


12
Saya lebih suka yang eksplisit if (some_flag == true)tapi implisit if (is_something)atau if (has_something). Perhatikan nama variabelnya.
fredoverflow

69
Ingatkan kolega Anda bahwa jenisnya someBool == truejuga boolean, jadi dengan logika yang sama seharusnya if ((someBool == true) == true).
Mike Seymour

2
@ GSto: Saya kira Anda tahu itu, tetapi dalam PHP Anda bisa melakukan itu untuk "membuang" apa saja menjadi bool dan sebenarnya bisa bermanfaat.
zneak

2
@ zneak Atau Anda bisa lebih jelas dan menggunakan $var = (bool) some_expression. Dan dalam kebanyakan kasus, itu bahkan tidak masalah karena PHP akan melakukan konversi yang diperlukan secara dinamis.
waiwai933

4
selalu periksa konstanta terlebih dahulu, if (true == someBool), jika Anda tidak sengaja mengetik = bukannya == [ya saya bercanda!]
Steven A. Lowe

Jawaban:


126

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

Jika itu sering terjadi, itu bisa menjadi masalah dengan bagaimana someBoolnamanya. Nama yang baik bisa sangat membantu menghilangkan kebutuhan untuk itu==true

if(IsSomeCondition)

atau

if(hasCondition)

atau

if(somethingExists)

sebagai contoh.


Cincin ini paling benar bagi saya. Ini semua tentang kejelasan dan seni penamaan, sintaks aslinya tidak terlalu buruk tapi ini adalah jalan yang benar untuk kode yang lebih baik.
TJB

2
Kalahkan aku! Tanpa penamaan yang tepat, kesetaraan yang lebih ringkas tidak masuk akal sama sekali.
Troy Hunt

4
Saya harus menggunakan someBool == truekode lama beberapa kali untuk kejelasan. Tetapi jika saya menulis dari awal saya if (isSomething)
beri

Saya setuju, Meskipun penamaan akan menyelesaikan ini, dengan asumsi nama adalah SomeBool, itu bisa berarti apa saja dan dari jenis apa pun (bilangan bulat sama dengan jumlah boolean dalam array mungkin?). Boolean membutuhkan semacam kata kerja eksistensial, atau mereka akan selalu sulit dibaca sendiri.
Morgan Herlocker

Saya setuju, ini semua tentang keterbacaan. Jika variabel dinamai dengan baik, Anda tidak membutuhkannya. Jika ungkapan itu berbunyi lebih baik dengan itu saya akan pergi untuk "== true", juga itu konsisten jika Anda menggunakan "== false" daripada (yang jelek) "if (! ())".
Ronny Brendel

71

Ketika saya melihat someBool == true, saya merasa seperti programmer belum menginternalisasi ide evaluasi , yang merupakan kekurangan yang cukup mendasar.

Namun, sudut pandang 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 pada masa-masa 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.


Saya tidak akan dengan cepat menghubungkan kebiasaan ini. Saya telah mendengar beberapa hal yang benar-benar menakjubkan dari mulut programmer profesional. Biasanya diikuti tak lama kemudian oleh salah satu pedagang gelap, "bagaimana ini bisa berhasil?"
dash-tom-bang

12
Setuju dengan sepenuh hati tentang evaluasi. Kadang-kadang saya bertanya-tanya, "Di mana itu berhenti?" if (((((x == true) == true) == true)! = false) // dan seterusnya ...
yawmark

1
Kadang-kadang saya akan menulis if (c == true) return true; else return false;, tetapi 99% dari waktu (1% ada di sana karena saya tidak pernah bisa memastikan bahwa saya tidak melewatkan beberapa) saya akan segera melihat dan mengganti semuanya dengan return c. Saya berharap sebagian besar programmer yang kompeten harus melakukan hal serupa jika mereka mengembangkan kebiasaan itu sejak awal karier mereka. Apa yang tidak saya harapkan adalah respons yang baik.
Lie Ryan

1
Oh boy, seni berpikir. Saya benar - benar menemukan ini di basis kode kami minggu lalu. if (!someCondition) { someCondition = false; }Saya telah melihat beberapa (er, banyak) redudansi serta beberapa ketidakmungkinan dalam kode kami, tetapi yang ini sangat sederhana namun begitu menjengkelkan untuk berpikir bahwa seseorang benar-benar menulisnya. Beberapa kali, bahkan.
Anthony Pegram

1
Catat saja bahwa saya telah melihat beberapa kasus if(x) x=true;yang TIDAK berlebihan, tetapi setara dengan x=!!x;(normalisasi x ke 0/1)
jkerian

58

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: Dapatkah 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, akan selalu dievaluasi menjadi benar.

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

if (someBool) {}

6
Ya, setuju. Ini konyol, tetapi Anda harus berkelahi, dan kode ini memang melakukan apa yang diinginkan rekan kerja Anda. Sebutkan dalam non- "Apa yang SALAH denganmu ?!" semacam cara, lalu jatuhkan. Meskipun jika mereka mulai menarik omong kosong seperti "jika (someBool! = Benar)" atau "jika (! SomeBool == benar)" atau konvolusi lainnya, itu mungkin pertarungan yang layak dipilih ....
BlairHippo

3
Bagaimana (someBool == false) lebih buruk daripada jika (someBool == benar)?
FinnNk

5
true=truetidak dikompilasi, Anda tidak dapat menetapkan untuk true;-)
fredoverflow

1
Saya sudah terbiasa if(somebool == false)atau !=, tetapi selalu menentang yang salah dan tidak benar. Saya menemukan itu berlebihan, tetapi karena standar pengkodean bersikeras bahwa if()terlihat seperti fungsi memanggil spasi antara parens membantu saya membacanya. Sendiri, bool adalah bool, tetapi if (somePointer)tidak bisa terbang; Saya lebih suka if (somePointer != NULL)karena pointer bukan bool.
dash-tom-bang

5
Ini tentang keterbacaan, bukan logika tidak logis atau (mikro)
Ronny Brendel

45

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


5
Yah, bagus untuk mengusahakan kesempurnaan tapi pasti ada ikan yang lebih besar untuk digoreng
TJB

3
Saya pikir Anda mengatakan ini tentang setiap masalah yang pantas didiskusikan.
Dave Van den Eynde

2
Ini berpotensi mengindikasikan masalah yang jauh lebih besar. Noda cokelat kecil di langit-langit di garasi Anda mungkin tidak terlihat seperti masalah besar, tetapi itu bisa berarti Anda mengalami kebocoran air besar.
Josh

42

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

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

if (someBool = true)

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


6
Ini bukan argumen yang relevan. Jika Anda menggunakan bahasa seperti itu, Anda bisa memindahkan yang benar ke sisi yang lain. Pertanyaannya adalah apakah memasukkan yang benar atau tidak.
Kamera

8
@Cam: Hilang intinya adalah Anda. Logika mundur saya tidak menyarankan.
Guffa

15
@Cam - Dia memberikan contoh dunia nyata kapan ini bisa menjadi masalah. Saya akan mengatakan ini sangat relevan.
ChaosPandion

1
@Guffa Cam sangat benar. Ini bukan alasan untuk berhenti menggunakan == (anyType) di blok if.
Ronny Brendel

2
@ Ronny: Tidak, itu tidak dapat terjadi dengan tipe apa pun (kecuali bahasa benar-benar memungkinkan jenis apa pun sebagai syarat). Pernyataan if (answer = 42) {}itu tidak bisa dikompilasi karena ekspresinya bukan bool.
Guffa

21

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
    //...
}

13
keterbacaan == GoodThing
Muad'Dib

5
if ((readability == GoodThing) == true) ...
JoelFan

1
bool isGoodThing = readibility? true: (codingStandards? true: (internalizationOfConcept? true: false));
JohnC

17
Jadi ganti nama variabelnya actionsAreAllowed.
Graeme Perrow

9
Dengan menulis if (x) { ...Anda sudah menyatakan bahwa itu xadalah boolean atau dapat dikonversi menjadi boolean. Apa yang Anda sebut itu tidak relevan.
Daniel Earwicker

15

Bagaimana dengan bool yang dapat dibatalkan?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

if (MyFlag.Value)
johnc

1
Tidak semua bahasa memiliki bool yang dapat dibatalkan, dan banyak dari mereka yang mau menerima konstruksi kedua Anda.
zneak

1
@johnc: "if (MyFlag.Value)" mungkin tidak benar-benar melakukan apa yang Anda inginkan karena dapat membuang pengecualian jika MyFlag adalah null (yang dapat Anda uji dengan memeriksa MyFlag.HasValue).
Ludovic Chabant

4
Ini adalah hewan peliharaan saya kesal dengan bools nullable :)
Jarrod Dixon

3
bool? isValid = null; if (isValid ?? false);
skolima

11

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 == truepernyataan bersyarat. Sebagai soal fakta, saya memiliki kebiasaan menggunakan == falsesebagai lawan dari 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.


1
Bergantung pada bahasa Anda, someValue mungkin tidak harus setara dengan true bahkan jika itu bernilai true. Sebagai contoh, (9 == True)mengevaluasi false dalam Python dan saya akan membayangkan serupa di C ++.
dash-tom-bang

kode wilayah dan garis bawah yang mengarah membuat saya ingin meninju orang.
MGOwen

11

Ack. Saya pria itu. Rasa malu, rasa malu. Begitulah cara saya belajar, dan itulah cara saya "memformat otomatis" di kepala saya. Satu-satunya saat 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.


7
Itu bukan hal yang buruk. Kode yang berbunyi seperti teks asli jauh lebih baik, daripada foo implisit. Pertahankan kebiasaan itu demi keterbacaan.
Ronny Brendel

11

ingatkan saya tentang "kode kegilaan boolean", seperti ini

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

Dari pada:

 otherBool = !someBool

Itu lucu, saya harus memelihara sistem yang telah mengotori mereka semua. Itu membuatku gila.
Tjaart

8

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

Karena itu saya menuliskannya secara lengkap:

if (someCondition == false) {

Setelah membaca itu sebentar, saya juga ingin simetri

if (someCondition == true) {

Jadi anggap saja ini sebagai artefak dari penggunaan C !alih-alih not.


3
C ++ sebenarnya memiliki para notoperator, dan begitu juga C (setelah Anda menyertakan header standar <iso646.h>). Jika Anda tidak ingin (atau tidak bisa) menggunakan header ini (atau jika Anda terjebak dengan Java atau C #), saya sarankan menempatkan spasi setelah tanda seru: if (! condition). Ini membuatnya agak lebih mencolok.
Konrad Rudolph

1
Saya menggunakan Java. notbukan pilihan.

6

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

Di C, jangan 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 ketika Anda mis-jenis =bukan ==, atau promosi kesalahan seperti yang disebutkan di komentar.


Sebenarnya, dalam bahasa di mana operator penugasan mengembalikan nilai ... seperti C ++ ... if (b == true) {tidak hanya berlebihan. Hal ini juga sedikit berisiko, karena Anda mungkin tidak sengaja ditugaskan trueuntuk b.
Stephen C

4
Ini bukan hanya berlebihan dalam C ++, itu berbahaya. Jika Anda menulis if (b == true), dan bbukan bool, jenis konversi salah arah. A booladalah tipe integral yang biasanya dipromosikan ke tipe integral yang sesuai dengan nilai 1. Jika Anda menulis, katakan, int b(2); if (b == true)kemudian truemenjadi intdengan nilai 1 untuk tujuan perbandingan, daripada bdipaksa menjadi tipe bool, yang akan memberikan hasil yang tepat.
David Thornley

@ Davidvidhorn, nyalakan peringatan di kompiler Anda. Memperlakukan peringatan sebagai kesalahan adalah teknik pemrograman defensif yang lebih baik daripada menghindari ==.
Abyx

5

Anda pikir itu buruk? Bagaimana tentang:

if(someCondition) {
  return true;
} else {
  return false;
}

2
Wah sudah berapa kali saya melihat ini. Ini membuat kasus yang bagus untuk alat seperti ReSharper.
Ayub

Ya - jika Anda menyewa gumpalan, maka belilah ReSharper.
Kirk Broadhurst

4

aku lebih memilih

if (bVal)

atau

if (!bVal)

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


4
Untuk cinta semua yang suci, asalkan tidak if (!bNotVal) atau if (bNotVal)bahkan di tempat pertama. Ugh negatif dalam nama membuat semuanya lebih sulit dibaca.
dash-tom-bang

2
Saya tahu seorang dev yang akan bool isNotConnected; if (isNotConnected == true) ... yuck
johnc

4

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.


3

Bagaimana tentang

if (x == "true")

MENGAPA ITU STRING ?!


Saya sedang mengerjakan beberapa kode php lama yang benar dan kadang-kadang saya menemukan sesuatu seperti if(preg_match('/title/', implode($_POST))){. PHP, cukup kata, saya perlu mencari pekerjaan yang lebih baik.
Keyo

4
ya, saya juga melihat apakah (x == "1"), tapi itu biasanya dilakukan pada desain db yang buruk.
atfergs

Saya telah menggunakan konstruksi serupa ketika xberasal dari input pengguna (file konfigurasi atau layanan web, misalnya). Namun, saya biasanya mengijinkan nilai truish lainnya, jadi akhirnya lebih sepertiif x.lower().strip() in ["true", "yes", "on", "1"]
eswald


3

Saya menulis kode seperti itu!

Inilah alasannya:

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

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

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


3
Anda mengatakan "jika bla" tidak berbunyi seperti kalimat ... itu berarti variabel Anda tidak dinamai dengan benar ... apa yang salah dengan ini: if (userHasRights) doSomething ()
JoelFan

"dalam banyak kasus". Ya kamu benar. Mengganti nama juga baik-baik saja. Dengan "if (QWidget :: acceptDrops () == true)" Anda tidak memiliki kemungkinan untuk mengganti nama. mungkin akan lebih baik untuk menamakannya doesAcceptDrops () ... Ini terlalu merepotkan (dan tidak mungkin untuk konsisten menggunakan aturan kelalaian dalam API apa pun), jadi konsisten dengan yang lain "== apa pun" -jika, Saya sangat menyarankan untuk tidak menghilangkannya, sehingga tidak "terlihat" berbeda, sehingga terlihat konsisten.
Ronny Brendel

3

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


2

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


3
Juga, jika itu dalam standar pengkodean tim, Anda benar-benar perlu mengevaluasi kembali standar untuk menyingkirkan hal-hal sepele seperti ini.
JohnFx

Sepakat! Hanya untuk berjaga-jaga ...
FinnNk

2

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

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, 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.


bool b;hanya menginisialisasi ke false ketika bbidang. Anda harus menginisialisasi variabel lokal secara eksplisit.
Matthew Flaschen

+1 setuju. Ini masalah yang sama dengan bahasa lain (scripting) juga. Anda harus eksplisit jika ingin menguji boolean trueatau hanya "benar". Misalnya, string apa pun yang tidak kosong dianggap == truetetapi tidak === truedalam beberapa bahasa.
Martin Wickman

2

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

Yang muda tahu aturannya, tetapi 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 tidak ada alasan untuk membandingkan sesuatu dengan true/ True. Namun, dalam Pythondan beberapa bahasa lain seperti C/C++Anda dapat melakukan ifpada ekspresi non-bool. Bahasa-bahasa ini memiliki aturan unik untuk menafsirkan bilangan bulat, pointer, daftar, dll. Baik benar atau salah. Terkadang Anda tidak menginginkannya. Misalnya, dalam cuplikan Python ini:

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

Di sini zseharusnya True, tetapi z2harus False. Sekarang, suatu Clojurebahasa mendekati ini dengan cara lain - andfungsi di sana tidak harus mengevaluasi ke a bool, tetapi ifdapat mengatasinya.

Terlepas dari bahasanya, setiap kali Anda menemukan diri Anda membandingkan sesuatu dengan Trueatau False, mungkin ada baiknya berkomentar.


Masalah pertama berasal dari premis palsu IMO dengan menggunakan nama-nama variabel yang mengerikan. X Misalkan, y, z diberi nama notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? Bagaimana hal itu membuat keterbacaan dalam masalah Anda? Jika x, y, z diberi nama seperti "isEnabled", "isEffective", "hasProperty", maka pernyataan Anda menjadi isEnabled || isEffective || hasPropertyyang jauh lebih mudah dibaca daripada membandingkan dengan trueatau false.
Thomas

1

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 sebagai "(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
Memiliki beberapaBool dapat menjadi sesuatu selain BENAR / SALAH adalah praktik pengkodean yang buruk.
AttackingHobo

@AttackingHobo, itu adalah salah satu jebakan dari tidak memiliki tipe boolean dalam bahasa dan / atau tidak menggunakan kelas untuk memberikan perilaku yang diinginkan.
Huperniketes

1

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

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 rakasa mirip 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 tipe yang ketat dalam bahasa ini, beberapa programmer lebih suka tidak harus bermain-main dengan false|undefinednilai - nilai.


1

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!


0

Saya akan mengatakan konsistensi adalah raja dalam basis kode. Jadi, Anda harus menggunakan gaya, yang sebagian besar digunakan di organisasi Anda. Cobalah menjadikan gaya yang Anda sukai menjadi bagian dari pedoman koding 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

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

bagaimana tentang:

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

Yap, saya sudah melihatnya.

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.