Machen Sie eine große Sache aus == wahr?

Es gibt einen Kollegen von mir, der ständig schreibt:

if (someBool == true)

Es treibt mich die Wand hoch! Soll ich eine große Sache daraus machen oder es einfach fallen lassen?

Es ist nur redundanter Code, nicht Leben oder Tod. Jedoch....

Wenn es viel passiert, könnte es ein Problem mit someBoolder Namensgebung geben. Ein guter Name kann einen großen Beitrag dazu leisten, die Notwendigkeit von==true

if(IsSomeCondition)

oder

if(hasCondition)

oder

if(somethingExists)

zum Beispiel.

Wenn ich sehe someBool == true, kann ich nicht anders, als das Gefühl zu haben, dass der Programmierer die Idee der Evaluierung nicht verinnerlicht hat , was ein ziemlich grundlegender Mangel ist.

Meine Sichtweise ist jedoch verzerrt, weil ich mehrere Sommer im College verbracht habe, um Kindern Programmieren beizubringen, die häufig solche Ausdrücke geschrieben haben, weil sie die mentale Übung, einen Ausdruck zu bewerten, nicht wirklich gemeistert haben. Sobald sie sich mit dem Konzept befasst hatten, wurde die Redundanz offensichtlich.

Für einen sonst kompetenten professionellen Programmierer ist dies wahrscheinlich nicht der Fall. Es ist wahrscheinlich nur eine schlechte Angewohnheit, die sie in ihren frühen Tagen des Programmierens entwickelt und nie ganz erschüttert haben. Aber es würde mich immer noch ein bisschen erschrecken, wenn es das erste war, was ich in einem Interview gesehen habe.

Das macht mich auch verrückt, aber ich würde ihnen die Redundanz konstruktiv erwähnen und sie dann fallen lassen, auch wenn sie nicht übereinstimmen.

Alternativ können Sie diesen Ansatz ausprobieren:
Sie: Können Sie beginnen, die folgende Codekonvention für die Auswertung von Booleschen Werten zu verwenden?

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

Sie: Warum sollten wir das tun? Die zweite Hälfte dieser Aussage ist überflüssig, sie würde immer als wahr gewertet.

Sie: Bei George, Sie haben Recht. Wie dumm von mir. Dann gehen wir einfach mit einer Version ohne Redundanz. Wie wäre es mit?

if (someBool) {}

Ich denke, wenn etwas so Triviales Ihr größtes Problem mit Ihren Mitarbeitern ist, sollten Sie sich für ziemlich glücklich halten.

Sie sollten diese schlechte Angewohnheit definitiv beenden. Sanft...

Es ist leicht zu vergessen, die doppelten Gleichheitszeichen zu schreiben und den Code in Folgendes umzuwandeln:

if (someBool = true)

In C # wird zum Beispiel nur eine Warnung ausgegeben, kein Fehler. Wenn Sie also Warnungen nicht als Fehler behandeln, wird der Code ausgeführt. Setzen Sie die Variable auf true und geben Sie immer die Bedingung ein.

Ich stimme dir zu, aber ich werde hier den Anwalt des Teufels spielen:

Abhängig von der Sprache und dem Namen der Variablen ist x == true angemessen:

Betrachten Sie die folgende Situation in einer Sprache mit statischer Typisierung und Typenzwang für ganzzahlige Typen:

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

Jemand, der diesen Codeabschnitt liest, erkennt möglicherweise nicht sofort, dass actionsAllowed eine boolesche Variable ist - es kann sich auch um eine Ganzzahl handeln, die die Anzahl der zulässigen Aktionen darstellt. Wenn Sie == true hinzufügen, wird klar, dass x ein Boolescher Wert ist und keine Ganzzahl, die zu einem Booleschen Wert gezwungen wird:

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

Was ist mit nullbaren Bools?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

Normalerweise möchten Sie nicht viel aus Kodierungskonventionen machen, es sei denn, diese Konvention behindert das Projekt in erheblichem Maße. Ich habe so manche hitzige Auseinandersetzung über Kleinigkeiten wie Coderegionen und führende Unterstriche eskalieren sehen.

Abgesehen davon sehe ich kein Problem darin == true, eine bedingte Anweisung zu ergänzen. In der Tat habe ich die Angewohnheit, == falsebeim Testen auf negative Bedingungen anstelle eines führenden Ausrufezeichens zu verwenden. Ich denke, es ist besser lesbar.

Wenn es eine festgelegte Konvention gibt, sage ich, befolge sie, es sei denn, es besteht Grund zur Änderung. Es lohnt sich jedoch nicht wirklich, einen großen Gestank hervorzurufen.

Ack. Ich bin dieser Typ. Die Schande, die Schande. So habe ich gelernt und so habe ich es in meinem Kopf "automatisch formatiert". Das einzige Mal, dass ich Joels bevorzugte Syntax verwende, ist, wenn die bool-Variable ein Verbpräfix wie "is" hat. Ich brauche das Verb, sei es "is", "can", "did" oder ich brauche das ==, um das Verb "equals" bereitzustellen. Ich werde diese Angewohnheit vielleicht nie aufgeben, also werde ich es verstehen, wenn Sie mir auf der Straße nicht „Hallo“ sagen.

erinnere mich an "Boolean Madness Code", es ist wie diese

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

Anstatt von:

 otherBool = !someBool

Persönlich mag ich es nicht, in C-basierten Sprachen "nicht" zu sagen. Das kleine Ausrufezeichen ist zu leicht zu übersehen.

Daher schreibe ich es vollständig aus:

if (someCondition == false) {

Nachdem ich das eine Weile gelesen habe, möchte ich auch Symmetrie mit

if (someCondition == true) {

Betrachten Sie es also als ein Artefakt von C !anstelle von not.

Das hängt von der Sprache ab, ist aber normalerweise eine schlechte Idee ...

Tun Sie dies in C niemals . Es ist zu einfach, eine Situation zu finden, in der der zu testende Wert nicht falsch (ungleich Null) ist, sondern auch nicht dem als "wahr" definierten Einzelwert entspricht.

Führen Sie dies in Ruby nur aus, wenn Sie absolut sicher sind, dass Sie bei allen außer Boolean true fehlschlagen möchten.

In C ++ und anderen statischen Sprachen mit einem Bool-Typ ist es redundant und kann zu Programmierfehlern führen, wenn Sie =anstelle von einen Tippfehler eingeben ==, oder zu Hochstufungsfehlern, wie in den Kommentaren erwähnt.

Findest du das schlecht? Wie wäre es mit:

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

ich bevorzuge

if (bVal)

oder

if (!bVal)

Auch, aber ich fürchte, dass es die Leute verärgert, wenn man es anspricht. Deshalb ist es mein Rat, es zu vergessen. Es tut uns leid!

Sie sollten ihm sagen, dass er es falsch macht.

es ist

if (true == someBool) {

}

wenn er jemals eines vergisst, hat er große Probleme mit seinem Schreibstil.

Wie wäre es mit

if (x == "true")

WARUM IST DAS EINE SAITE ?!

Tatsächlich wäre ein Test auf x == true erforderlich, wenn es nullbar ist. :)

Ich schreibe so Code!

Hier ist warum:

"if bla == true" liest sich wie ein Satz, "if bla" in vielen Fällen nicht. Es klingt einfach falsch, wenn man den aktuellen Code liest.

Außerdem warnt der Compiler vor Zuweisungen in if-Blöcken, sodass die Verwendung von == true keine Gefahr darstellt. (Verwechslung mit =)

Verwenden auch Leute, die nicht "== true" schreiben, das "! ()" Für "== false"? Ich finde es wirklich hässlich. Und wenn Sie "== false" verwenden, ist es nur sehr konsequent, auch "== true" zu verwenden, anstatt zwei verschiedene Möglichkeiten zur Überprüfung der Wahrheit zu haben.

Denken Sie daran, dass Sie als Teil eines Teams arbeiten. Deshalb müssen Sie diese Dinge gemeinsam erarbeiten. "Plays nice with others" ist auch nach der Grundschule ein wichtiges Persönlichkeitsmerkmal :)

Im Allgemeinen wird das '== true' weggelassen, aber es ist kaum eine Minute wert, darüber zu diskutieren, es sei denn, Sie haben es in den Codierungsstandards Ihres Teams enthalten.

Obwohl ich als hauptsächlich C # -Entwickler zustimme, kann ich nicht sagen, dass dies immer der Fall ist. In Javascript führt das === beispielsweise eine Typkoaleszenz durch. Angenommen also var x = 3, dann:

if(x) --> true

während

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

Ich denke, das ist etwas anderes als ==, da ich selbst in JS nicht if (x == true) verwenden würde, sondern nur etwas, worüber ich nachdenken müsste .

Diese Art von Berührungen berühren jedoch einen anderen Punkt, der in meinem Büro aufgetaucht ist:

bool b = false;

In C # ist bool b; wäre genug und würde b zu falsch initialisieren . Es ist jedoch expliziter, die obige Zeile zu schreiben und sollte trotzdem vom Compiler während der Optimierung herausgerissen werden.

Mein Punkt ist also, dass es nicht immer so offensichtlich ist, was eine gute Praxis ist und was nicht. Vieles hängt von Vorlieben und Sprachfeatures / Macken ab.

Ah ja, aber was ist, wenn die Variable nullbar ist? (Bool?)

Einige Sprachen (C #) erfordern und cast oder Vergleich mit "true".

bool? isAccepted = true;

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

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

Die Jungen kennen die Regeln, aber die Alten kennen die Ausnahmen;)

C#Wenn Sie sich mit einem beschäftigen null-able bool, müssen Sie spätestens :

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

Wenn Tristate kein Problem ist, sollte es normalerweise keinen Grund geben, etwas mit true/ zu vergleichen True. In und in Pythonmehreren anderen Sprachen C/C++können Sie jedoch einen ifAusdruck ausführen, der nicht bool ist. Diese Sprachen haben eindeutige Regeln für die Interpretation von Ganzzahlen, Zeigern, Listen usw. als wahr oder falsch. Manchmal willst du das nicht. Zum Beispiel in diesem Python-Snippet:

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

Hier zsollte sein True, z2sollte aber sein False. Nun Clojurenähert sich eine Sprache dies auf eine andere Art und Weise - da wird die andFunktion nicht unbedingt als a bewertet bool, aber die ifkann damit umgehen.

Unabhängig von der Sprache lohnt es sich wahrscheinlich, Kommentare abzugeben, wenn Sie etwas mit Trueoder vergleichen False.

Eine solche Kodierung hätte mich auch schon früher falsch gerieben. Obwohl Ihr Beispielbezeichner den Namen "someBool" trägt, kann die versehentliche Verwendung dieses Codierungsstils für eine Variable, für die nicht garantiert wurde, dass sie ein Boolescher Wert ist, zu unbeabsichtigtem Verhalten führen. Wenn der Wert von "someBool" nicht genau "true" oder "false" ist, ist das Ergebnis "false".

Ich bin im vergangenen Jahr auf einen sehr subtilen Fehler gestoßen, der durch einen solchen Codierungsstil verursacht wurde, der schwer zu identifizieren war, weil die Augen über solchen Konstrukten glänzten. Sie würden denken, "Wie könnte es falsch sein?" Dasselbe gilt für wohlverstandene Ausdrücke wie "(var)" oder "(! Var)", die Sie lesen oder codieren, ohne ihr Verhalten zu überprüfen.

Deshalb habe ich einige Codierungsstandards eingeführt, um die Existenz solcher Fehler in der Codebasis und die Wahrscheinlichkeit, dass sich solche subtilen Fehler in Zukunft versehentlich einschleichen, zu verringern.

1. Alle Ausdrücke müssen in Klammern angegeben werden.
2. Alle booleschen Tests müssen negativ sein, wie "suchBool! = False".

Durch die Bereinigung von Code, der nicht dem neuen Stil entspricht, habe ich einige weitere Fälle solcher subtiler Fehler identifiziert und korrigiert.

Musste dies die ganze Zeit in ActionScript 2 verwenden (zugegebenermaßen jetzt eine tote Sprache), weil:

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

Es war also fast immer das Beste, genau zu sein.

Genau. Es ist eine redundante Konstruktion, insbesondere in stark getippten Sprachen.

Um einen weiteren Missbrauch von Booleschen Werten hinzuzufügen, habe ich diese Art von Konstruktion einige Male in Javascript gefunden (insbesondere bei einigen spaghettiartigen Monsterfunktionen, wie in über 100 Zeilen):

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

Es scheint, dass einige Programmierer es aufgrund des Fehlens einer strengen Typdefinition in dieser Sprache vorziehen, nicht mit den false|undefinedWerten herumzuspielen .

Ich habe einen Kollegen, der einen Code wie diesen haben wird:

if(something == true)

Und dann möchte er für eine Art Test / Debugging diesen Block nicht aufrufen und ändert ihn in:

if(something == true && false)

Und dann ändert er es gelegentlich zu:

if(false)

Das Schlimmste ist, diese Art des Debuggens hat sich bei mir gelegentlich ausgewirkt und ist für andere Entwickler wirklich schlecht zu lesen!

Ich würde sagen, Konsistenz ist das A und O in einer Codebasis. Verwenden Sie daher den Stil, der in Ihrer Organisation am häufigsten verwendet wird. Versuchen Sie, Ihren bevorzugten Stil in die offiziellen Kodierungsrichtlinien des Unternehmens aufzunehmen. Wenn es bereits in den Richtlinien steht, befolgen Sie es einfach.

(Abgesehen davon würde es mich auch sehr ärgern - aber wahrscheinlich nicht genug, um eine große Sache daraus zu machen).

Ich ziehe es vor, das Extra nicht zu setzen == true, aber manchmal füge ich es versehentlich hinzu und bemerke es nicht. Die Person hat sie möglicherweise nicht bemerkt und sie versehentlich platziert. Ich lese meinen Code noch einmal und stelle manchmal fest, dass ich das zusätzliche == true eingefügt habe, damit ich das == true entferne. Ich bemerke es manchmal nicht und würde mich freuen, wenn jemand mir sagte, ich hätte es überflüssig gemacht.

wie wäre es mit:

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

Ja, ich habe es gesehen.