it-swarm.dev

== doğru büyük bir anlaşma yapmak?

Sürekli yazan bir meslektaşım var:

if (someBool == true)

Beni duvara doğru itiyor! Büyük bir şey yapmalı mıyım yoksa bırakmalı mıyım?

105
JoelFan

Bu sadece gereksiz kod, hayat ya da ölüm değil. Ancak....

Çok şey oluyorsa, someBool'nin nasıl adlandırıldığıyla ilgili bir sorun olabilir. İyi bir isim, ==true

if(IsSomeCondition)

veya

if(hasCondition)

veya

if(somethingExists)

örneğin.

126
Robert Harvey

Gördüğüm zaman someBool == true, Yardım edemiyorum ama programcı değerlendirme fikrini içselleştirmemiş gibi hissediyorum, ki bu oldukça temel bir eksiklik.

Bununla birlikte, bakış açım çarpık çünkü kolej öğretiminde, bu tür ifadeleri sık sık yazan çocuklara programlama öğretimi yapmak için birkaç yaz geçirdim çünkü gerçekten bir ifadeyi değerlendirme zihinsel egzersizi üzerinde ustalaşmamışlardı. Kavramı bir kez inceledikten sonra artıklık belirginleşti.

Aksi takdirde yetkin bir profesyonel programcı için durum böyle değildir. Muhtemelen programlamanın ilk günlerinde geliştirdikleri kötü bir alışkanlıktır ve hiçbir zaman tam olarak sarsılmamıştır. Ama birisinin röportajda ilk gördüğüm şey beni korkuturdu.

71
Tim Goodman

Bu da beni deli ediyor, ama yapıcı bir şekilde onlara fazlalıktan söz ediyorum ve sonra aynı fikirde olmasalar bile düşüyorlar.

Alternatif olarak bu yaklaşımı deneyebilirsiniz:
Siz: Boole'ları değerlendirmek için aşağıdaki kod kuralını kullanmaya başlayabilir misiniz?

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

Onları: Bunu neden yapalım? Bu ifadenin ikinci yarısı gereksizdir, her zaman doğru olarak değerlendirilir.

Siz: George tarafından haklısınız. Aptal bana. O zaman tüm artıklık olmadan bir versiyona gidelim. Nasıl?

if (someBool) {}
58
JohnFx

Bence, bu kadar önemsiz bir şey iş arkadaşlarınızla en büyük probleminizse, kendinizi oldukça şanslı görmelisiniz.

45
GrandmasterB

Bu kötü alışkanlığı kesinlikle durdurmalısın. Nazikçe...

Kodu eşitleyerek çift eşit işareti yazmayı unutmak kolaydır:

if (someBool = true)

Örneğin C # 'da bu bir hata değil, yalnızca bir uyarı üretecektir. Bu nedenle, uyarıları hata olarak değerlendirmezseniz, kod çalıştırılır, değişkeni true olarak ayarlayın ve her zaman koşulu girin.

42
Guffa

Sana katılıyorum, ama burada şeytanın avukatını oynayacağım:


Dile ve değişkenin adına bağlı olarak, x == true uygundur:

İntegral türler için statik yazım ve tür baskısı olan bir dilde aşağıdaki durumu göz önünde bulundurun:

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

Kodun bu bölümünü okuyan biri, actionsAllowed öğesinin bir boole değişkeni olduğunu hemen fark etmeyebilir - izin verilen eylem sayısını temsil eden bir tam sayı da olabilir. == true ekleyerek x'in bir boole olduğu ve bir boole için zorlanan bir tamsayı olmadığı anlaşılıyor:

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

Sıfırlanabilir booller ne olacak?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

Tipik olarak, söz konusu sözleşme bir şekilde projeyi önemli ölçüde engellemedikçe, kodlama kurallarından çok şey yapmak istemezsiniz. Kod bölgeleri ve önde gelen alt çizgiler kadar küçük şeylere tırmanan pek çok ateşli argüman gördüm.

Olduğu söyleniyor, == true koşullu ifadeye. Aslına bakarsanız, == false, negatif koşulları test ederken önde gelen bir ünlem işareti yerine. Bence daha okunabilir.

Yerleşik bir sözleşme varsa, değiştirmek için bir neden olmadığı sürece takip edin diyorum. Ancak, bu konuda büyük bir koku yaratmaya değmez.

11
Casey

Ack. Ben o adamım. Utanç, utanç. Bu şekilde öğrendim ve kafamda "otomatik biçimlendiriyorum". Joel'in tercih ettiği sözdizimini kullandığım tek şey, bool değişkeninin "is" gibi bir fiil önekinin olması. "Bu", "" olabilir, "" yaptı "ya da başka bir fiil" eşittir "fiili sağlamak için == gerekir. Asla bu alışkanlığı kıramayacağım, bu yüzden sokakta bana 'merhaba' demezsen anlayacağım.

11
Scott Fletcher

"boolean delilik kodu" nu hatırlat

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

Onun yerine:

 otherBool = !someBool
11

Şahsen, C tabanlı dillerde "değil" demenin yolunu sevmiyorum. Bu küçük ünlem işaretini göz ardı etmek çok kolay.

Bu yüzden tam olarak yazıyorum:

if (someCondition == false) {

Bir süre okuduktan sonra benimle simetri istiyorum

if (someCondition == true) {

Bu yüzden not yerine ! Kullanarak C'nin bir yapısını düşünün.

8
user1249

Dile bağlı, ancak genellikle kötü bir fikir ...

C olarak, asla bunu yapın. Test ettiğiniz değerin yanlış (sıfırdan farklı) olmadığı, aynı zamanda "true" olarak tanımlanan tek değere eşit olmadığı bir durum bulmak çok kolaydır.

Ruby'de bunu yalnızca Boolean true dışındaki her şeyde başarısız olmak istediğinizden kesinlikle eminseniz yapın.

C++ ve bool türüne sahip diğer statik dillerde, gereksizdir ve = onun yerine == veya yorumlarda belirtildiği gibi tanıtım hataları.

6
AShelly

Sence bu kötü mü? Nasıl olur:

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

Tercih ederim

if (bVal)

veya

if (!bVal)

ama korkarım ki onu büyütmek insanları kızdırır, bu yüzden tavsiyem unutmaktır. Afedersiniz!

4
grokus

ona yanlış yaptığını söylemelisin.

onun

if (true == someBool) {

}

eğer birini unutursa = yazı tarzında büyük beladadır.

4
Display Name

Peki ya

if (x == "true")

NEDEN IS BU BİR STRING ?!

3
atfergs

Aslında, boş değer varsa, x == true için test yapılması gerekir. :)

3
Matt Sherman

Ben böyle kod yazıyorum!

İşte nedeni:

"if bla == true" bir cümle gibi okunur, burada "if bla" pek çok durumda değildir. Gerçek kodu OKUYORSA, sadece yanlış geliyor.

Derleyici if bloklarında atamalar hakkında uyarır, bu nedenle == true kullanmanın gerçekten bir tehlikesi yoktur. (= ile karıştırıyorum)

Ayrıca "== true" yazmayan çocuklar, "== false" için "! ()" Kullanın? Gerçekten çirkin buluyorum. "== false" kullanırsanız, gerçeği doğrulamanın iki farklı yoluna sahip olmak yerine "== true" ifadesini kullanmak da çok tutarlıdır.

3
Ronny Brendel

Bir ekibin parçası olarak çalıştığınızı unutmayın, bu nedenle bunları birlikte çalışmanız gerekir. "Başkalarıyla güzel oynar" ilkokuldan sonra bile önemli bir kişilik özelliğidir :)

3
cdkMoose

Genellikle '== true' değerini atlar, ancak ekibinizin kodlama standartlarına dahil olmadıkça tartışmak bile bir dakikanızı ayırmaya değer değildir.

2
FinnNk

Ben esas olarak bir C # geliştirici olarak kabul ederken, bu her zaman böyle olduğunu söyleyemeyiz. Örneğin, Javascript'te === tür birleşmesi gerçekleştirir. Yani var x = varsayalım:

if(x) --> true

süre

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

Sanırım bu == farklı çünkü JS bile ben --- kullanmazdım eğer (x == true) ama sadece düşünmek için bir şey.

Ofisimde ortaya çıkan başka bir noktada bu tür dokunuşlar:

bool b = false;

C # 'da bool b; yeterli olur ve b - yanlış değerini geçersiz kılar. Bununla birlikte, yukarıdaki satırı yazmak daha açıktır ve yine de optimizasyon sırasında derleyici tarafından sökülmelidir.

Demek istediğim, iyi uygulamaların ne olduğu ve ne olmadığı o kadar açık değildir ve birçoğu tercihlerin yanı sıra dil özelliklerine/tuhaflıklarına dayanmaktadır.

2
statichippo

Ah evet, ama değişken null edilebilirse? (Bool?)

Bazı diller (C #) 'gerçek' gerektirir ve yayınlar veya karşılaştırır.

bool? isAccepted = true;

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

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

Gençler kuralları biliyor, ancak yaşlılar istisnaları biliyor;)

En son C#, bir null-able bool, o zaman yapmanız gerekenler:

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

Eğer tristat bir problem değilse, genellikle true/True ile karşılaştırmak için bir neden olmamalıdır. Ancak, Python ve C/C++ bool olmayan bir ifade üzerinde if gerçekleştirebilirsiniz. Bu diller, tamsayıları, işaretçileri, listeleri vb. Doğru veya yanlış olarak yorumlamak için benzersiz kurallara sahiptir. Bazen bunu istemezsin. Örneğin, bu Python snippet'inde:

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

Burada zTrue olmalı, ancak z2False olmalıdır. Şimdi, bir Clojure dili buna başka bir şekilde yaklaşıyor - orada and işlevi mutlaka bool değerini değerlendirmiyor, ancak if bunu işleyebilir.

Dilden bağımsız olarak, bir şeyi True veya False ile karşılaştırdığınızda, muhtemelen yorum yapmaya değer.

2
Job

Böyle bir kodlama daha önce beni yanlış şekilde ovuştururdu. Örnek tanımlayıcınız "someBool" olarak adlandırılsa da, bu kodlama stilini yanlışlıkla bir boole olması garanti edilmeyen bir değişken üzerinde kullanmak istenmeyen davranışlara sahip olabilir. "SomeBool" değeri tam olarak "true" veya "false" değilse, sonuç false olur.

Geçtiğimiz yıl bu tür kodlama stilinin neden olduğu çok ince bir hatayla karşılaştım çünkü birinin gözleri bu tür yapılar üzerinde parlıyor. "Nasıl yanlış olabilir?" Aynı şey, davranışlarını doğrulamadan bunları okuduğunuz veya kodladığınız "(var)" veya "(! Var)" gibi iyi anlaşılmış ifadeler için de geçerlidir.

Bu yüzden, kod tabanında bu tür hataların varlığını ve gelecekte bu tür ince hataların yanlışlıkla bir süre içinde sürünme olasılığını azaltmak için birkaç kodlama standardı tanıttım.

  1. Tüm ifadeler, amaçlarına göre parantez içine alınmalıdır.
  2. Tüm boolean testleri, "suchBool! = False" gibi negatif olarak ifade edilmelidir.

Yeni stile uygun olmayan kodu temizleyerek, bu tür ince hataların birkaç örneğini tanımladım ve düzelttim.

1
Huperniketes

Bunu ActionScript 2'de (kuşkusuz artık ölü bir dil) kullanmak zorunda kaldım, çünkü:

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)
{
}

Bu yüzden spesifik olmak neredeyse her zaman en iyisiydi.

1
bburbank

Katılıyorum. Özellikle güçlü yazı dillerinde, gereksiz bir yapıdır.

Booleanların başka bir kötüye kullanımını eklemek için, bu tür bir yapıyı Javascript'te birkaç kez buldum (özellikle 100+ satırda olduğu gibi spagetti benzeri bazı canavar fonksiyonlarında):

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

Görünüşe göre, bu dilde katı bir tür tanımının bulunmaması nedeniyle, bazı programcılar false|undefined değer.

1
Tomas Narros

Ben böyle bir kod olacak bir meslektaşım var:

if(something == true)

Ve sonra, bir tür test/hata ayıklama için, bu bloğu çağırmak istemeyecek, böylece onu şu şekilde değiştirecek:

if(something == true && false)

Ve sonra zaman zaman bunu şu şekilde değiştirir:

if(false)

En kötü şey, bu tür hata ayıklama zaman zaman bana ovuşturdu ve diğer geliştiriciler okumak için gerçekten kötü!

1
ingh.am

Kod tabanında tutarlılığın kral olduğunu söyleyebilirim. Bu nedenle, stili kullanmalısınız, yani kuruluşunuzda kullanılan çoğunlukla. Tercih ettiğiniz stili resmi şirket kodlama yönergelerinin bir parçası yapmaya çalışın. Zaten yönergelerde bulunuyorsa, sadece izleyin.

(Olduğu söyleniyor, bu beni gerçekten kızdırır - ama muhtemelen ondan büyük bir anlaşma yapmak için yeterli değildir).

0
driis

Ekstra == doğru yerleştirmemeyi tercih ederim, ancak bazen yanlışlıkla dahil ediyorum ve fark etmiyorum. Kişi fark etmemiş ve yanlışlıkla yerleştirmiş olabilir. Kodumu tekrar okudum ve bazen ekstra == true yerleştirdiğini fark ettim, bu yüzden == true. Bazen fark etmiyorum ve birisini bana fazladan yerleştirdiğimi söyleyerek memnuniyetle karşılarım.

0
sange

Meslektaşım if a loop olarak adlandırdı. Bunu anlatmak için yaşadım.

0

WPF'de çok fazla programlama yaparken bu alışkanlık geliştirilebilir. Çok sayıda bool kullanıyor mu? (boş değer bool) değişkenleri if (someBool == true) veya if (someBool ?? false) yazmak zorunda.

0
Poma

İnşallah, Option Strict On özelliğine sahip VB.NET gibi mantıklı bir dil kullanıyorsunuz. O zaman zorlama durumu gerçekleşemeyeceğinden, "== true" (veya VB'de "= True") eklemenize gerek yoktur. Sıfırdan farklı olup olmadığını kontrol etmek istiyorsanız, bunu açıkça yazın (ör., "If x <> 0").

0
o. nate

nasıl:

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

Evet, gördüm.

0
Dave

Acemi bir geliştirici için bir kod kokusu. Henüz boolean koşuluna hakim/içselleştirilmemişlerdir ve doğru veya yanlış koşulu açıkça değerlendirmelidirler.

0
Chuck Conway

JavaScript'te, yöntemin ne beklediğini açıklayan yeterli belgelere sahip olduğumda if(bool) tercih ederim ... ancak değerlendirme true değişkenin var olduğu anlamına gelebilir, 1 sayısına veya boole eşittir doğru, daha zor.

JS'ye güçlü bir şekilde yazmak, daha az esneklik anlamına da gelir. Zor çağrı. Güçlü yazılmış diller, çekiçleri yerleştirin. Aksi halde, neden yaptığını sorun.

Aslında cevabınız var: ona nedenini sorun. Sonra onu düzeltin.

0
Clint

ona öğretmek için bir fırsat olarak kullanın. eğer yaparsan sana daha fazla saygı duyacaktır. birisinin sizin için aynısını yapmasını istemez miydiniz?

0
Rush Frisby

Araştırmalar, fazlalık içeren kodun hatalarla güçlü bir şekilde ilişkili olduğunu göstermektedir. İşte konuyla ilgili ilginç bir kağıt (PDF uyarısı).

0
David Plumpton

Boolean'ları karşılaştırmak aslında büyük sorunlara neden olabilir. Son zamanlarda okudu bazı stajyer koduna koştu:

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

Şimdi, bu oldukça basit görünüyor, değil mi? Sadece basitleştirin:

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

Yanlış. Bu durumda, işlem sırası && Öğesinin ilk önce değerlendirilmesini gerektirir;

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

ayrıca şöyle bilinir

if(!foo)

bar == 2 İçin kontrol etmemiz gereken ekstra şey tamamen gitti. Bu yüzden someBool == [true|false] İçeren bir kod incelemesini asla onaylamam.

(Ters ifadenin, == true Ve || Öğelerinin de nasıl sorunlara neden olduğunu görebilirsiniz.)

0
tghw

Evet, bu bir tür programcı zihin seti. Her zaman "eğer koşul" ifadesi, =, <,> sembolleriyle bir ifade olmadan varolduğunu düşünürler ... İnsanların gerçekten "işlev geri dönüşü" gibi mücadele ettiği durumları gördüm

if (RowsAffected> 0) {true değerini döndürür; } else {dönüş yanlış; }

Programcıların kodlarını gerçek zamanlı açıdan izlemeleri gerekir .. :)

0
Krishna Prasad A

C'deki bir sorun, booleanlar için 0 ve 1 dışındaki değerleri kullanma geleneğinin olmasıdır.

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

hatta -1'in doğru olduğuna güvenmek.

Sorun şu ki bir API yazıyorsunuz:

struct foo { 
  unsigned int bar : 1;
};

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

Burada çubuk 0 veya 1'e standartlaştırılmazsa, bit alanına sığmaz ve kırılır:

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

Kanonik olmayan bobinlerin kırılmasının diğer yollarını da bulabilirsiniz; örneğin, sorudaki gibi DOĞRU veya YANLIŞ ile karşılaştırmak!

Her neyse, buraya geliyorum, genellikle bir boolu kanonikleştirmenin mantıklı olması:

foo->bar = bar != FALSE;

Bu elbette C'ye özgü bir tuhaflık.

0
Havoc P

Evet, çok önemli çünkü booleanın adı boolean olduğunu söylemelidir. Bu kod parçasına sahip olup olmadığını söyler:

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

Okuması zaten kolaydır, bu yüzden == true, daha az değerlendirme duygusu olan kişi veya programcı için bile.

0
tia

Programlama kuralları mutlaka "doğru" veya "yanlış" değildir. Programı okuyanlara tanıdık bir yapı kazandırmak için varlar, böylece olası hatalar daha açık bir şekilde ortaya çıkacak - her şey size biraz yanlış bakıyorsa bir sorunu "görmek" zordur.

Önemli olan, sözleşmelerin tüm katılımcılar tarafından açıkça tanımlanması ve üzerinde anlaşmaya varılmasıdır (anlaşma "burada çalışırken bu sözleşmeyi kullanmayı kabul ediyorum" :) gibi olsa bile, aksi takdirde yarardan çok zarar verir.

Tabii ki, özellikle bir mantıksal ile doğru karşılaştırılması oldukça basittir ve her ne pahasına olursa olsun kaçınılmalıdır. ;-)

0
Daniel C. Sobral

Ben yazıyorum (var == yanlış) çünkü var yazdıktan sonra geri izleme ve yazma gibi hissetmiyorum! arkasında. Ayrıca nasıl == false daha net görünmesini sağlar gibi.

Ancak == true sadece garip. Büyük bir anlaşma yapmanın bir anlamı olup olmadığını bilmiyorum. Başkalarını kullanmak veya bir kodlama standardı yapmak için bastırıyor sürece ben olmaz.

0
user2528

Aşağıdaki örnekle meslektaşınıza yaklaşmayı deneyebilirsiniz:

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

== true yedeklidir ve şu şekilde yeniden yazılmalıdır:

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

dan beri x == 3 zaten bir boole ifadesidir.

Şimdi ona someBool == true örnek, ancak biraz yeniden yazılmış:

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

someBool zaten bir boole olduğundan, önceki örneğe kıyasla, == true bu örnekte de gereksizdir. Bu nedenle, şu şekilde yeniden yazılmalıdır:

if (someBool) {
    ...
}
0
gablin

Komik çünkü her zaman kodu değiştirmek gibi:

if(foo) {

İle:

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

Ama bu alışkanlığı aldım çünkü çoğu zaman birlikte çalıştığım kodun açık değişken isimleri yoktu.

0
mhitza

Bu, bazı nişancılarınızı bir tomarda alabilir.

Bool türü için .IsTrue ve .IsFalse için uzantı yöntemlerimiz var.

Bu yüzden yazıyoruz

eğer (someBool.IsTrue ())

-veya-

eğer (someBool.IsFalse ())

Evet! Ve onları seviyorum. Kodu okurken benim için daha belirgin hale geliyor.

0
ElGringoGrande