it-swarm-eu.dev

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?

105
JoelFan

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

Wenn es viel passiert, kann es ein Problem sein, wie someBool benannt wird. Ein guter Name kann viel dazu beitragen, die Notwendigkeit des ==true

if(IsSomeCondition)

oder

if(hasCondition)

oder

if(somethingExists)

zum Beispiel.

126
Robert Harvey

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

Meine Perspektive 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, wirklich nicht gemeistert hatten. Sobald sie das Konzept durchgearbeitet hatten, wurde die Redundanz offensichtlich.

Für einen ansonsten 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 wäre, was ich in einem Interview von jemandem sehen würde.

71
Tim Goodman

Das macht mich auch verrückt, aber ich würde sagen, erwähnen Sie die Redundanz auf konstruktive Weise und lassen Sie sie dann fallen, auch wenn sie nicht übereinstimmen.

Alternativ können Sie diesen Ansatz ausprobieren :
Sie : Können Sie die folgende Codekonvention zur Bewertung von Booleschen Werten verwenden?

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

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

Sie : Von George, Sie haben Recht. Wie dumm von mir. Lassen Sie uns dann einfach mit einer Version ohne Redundanz gehen. Wie wäre es mit?

if (someBool) {}
58
JohnFx

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

45
GrandmasterB

Sie sollten diese schlechte Angewohnheit auf jeden Fall beenden. Sanft...

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

if (someBool = true)

In C # wird beispielsweise 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.

42
Guffa

Ich stimme Ihnen 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 integrale Typen:

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

Jemand, der diesen Abschnitt des Codes liest, erkennt möglicherweise nicht sofort, dass actionAllowed eine boolesche Variable ist - es kann sich auch um eine Ganzzahl handeln, die die Anzahl der zulässigen Aktionen darstellt. Durch Hinzufügen von == true 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
    //...
}
21
Cam

Was ist mit nullbaren Bools?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

Normalerweise möchten Sie aus Codierungskonventionen keine große Sache machen, es sei denn, diese Konvention behindert das Projekt in signifikanter Weise. Ich habe viele hitzige Auseinandersetzungen gesehen, die über Dinge eskalierten, die so klein waren wie Code-Regionen und führende Unterstriche.

Davon abgesehen sehe ich kein Problem beim Hinzufügen von == true zu einer bedingten Anweisung. Tatsächlich habe ich die Angewohnheit, == false im Gegensatz zu einem führenden Ausrufezeichen beim Testen auf negative Bedingungen. Ich denke, es ist besser lesbar.

Wenn es eine etablierte Konvention gibt, sage ich, folge ihr, es sei denn, es gibt Grund zur Änderung. Es lohnt sich jedoch nicht wirklich, einen großen Gestank zu erregen.

11
Casey

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

11
Scott Fletcher

erinnere mich an "boolean madness code", es ist wie diese

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

Anstatt:

 otherBool = !someBool
11

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 mit ! anstelle von not.

8
user1249

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

In C, nie mach das. 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.

Tun Sie dies in Ruby nur, wenn Sie absolut sicher sind, dass Sie bei allem außer Boolean true fehlschlagen möchten.

In C++ und anderen statischen Sprachen mit einem Bool-Typ ist dies redundant und kann zu Programmierfehlern führen, wenn Sie = Anstelle von == Falsch eingeben, oder zu Heraufstufungsfehlern, wie in den Kommentaren erwähnt.

6
AShelly

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

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

Ich bevorzuge

if (bVal)

oder

if (!bVal)

auch, aber ich befürchte, dass das Ansprechen die Leute verärgern würde, also ist mein Rat, es zu vergessen. Es tut uns leid!

4
grokus

sie sollten ihm sagen, dass er es falsch macht.

es ist

if (true == someBool) {

}}

wenn er jemals einen vergisst = er hat große Probleme mit seinem Schreibstil.

4
Display Name

Wie wäre es mit

if (x == "true")

WARUM IS DAS EIN STRING?!

3
atfergs

Wenn es nullbar ist, wäre es tatsächlich notwendig, auf x == true zu testen. :) :)

3
Matt Sherman

Ich schreibe so einen Code!

Hier ist warum:

"if bla == true" liest sich wie ein Satz, während "if bla" dies in vielen Fällen nicht tut. Es klingt einfach falsch, wenn der eigentliche Code gelesen wird.

Außerdem warnt der Compiler vor Zuweisungen in if-Blöcken, sodass bei der Verwendung von == true keine Gefahr besteht. (verwechselt es 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 konsistent, auch "== true" zu verwenden, anstatt zwei verschiedene Möglichkeiten zur Überprüfung der Wahrheit zu haben.

3
Ronny Brendel

Denken Sie daran, dass Sie als Teil eines Teams arbeiten, also müssen Sie diese Dinge gemeinsam ausarbeiten. "Spielt schön mit anderen" ist auch nach der Grundschule noch ein wichtiges Persönlichkeitsmerkmal :)

3
cdkMoose

Im Allgemeinen wird das '== true' weggelassen, aber es lohnt sich kaum, eine Minute darüber zu diskutieren, es sei denn, Sie haben es in die Codierungsstandards Ihres Teams aufgenommen.

2
FinnNk

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 Typverschmelzung durch. Nehmen wir also an var x = dann:

if(x) --> true

während

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

Ich denke, das ist anders als ==, da ich selbst in JS nicht if (x == true) verwenden würde, sondern nur etwas zum Nachdenken.

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

bool b = false;

In C # würde bool b; ausreichen und b zu false initialisieren. Es ist jedoch expliziter, die obige Zeile zu schreiben, und sollte auf jeden Fall vom Compiler während der Optimierung herausgerissen werden.

Ich denke, mein Punkt ist, dass es nicht immer so offensichtlich ist, was eine gute Praxis ist und was nicht, und vieles davon läuft auf Vorlieben sowie Sprachmerkmale/Macken hinaus.

2
statichippo

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

Einige Sprachen (C #) erfordern und besetzen oder vergleichen mit 'true'.

bool? isAccepted = true;

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

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

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

Wenn Sie im neuesten C# Mit einem null-able bool Beschäftigen, müssen Sie:

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/True zu vergleichen. In Python und mehreren anderen Sprachen wie C/C++ Können Sie jedoch ein if für einen Nicht-Bool-Ausdruck ausführen. 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 sollte zTrue sein, aber z2 Sollte False sein. Nun, eine Clojure Sprache nähert sich dem auf noch eine andere Weise - dort wird die Funktion and nicht unbedingt zu einem bool ausgewertet, aber das if kann damit umgehen.

Unabhängig von der Sprache lohnt es sich wahrscheinlich, jedes Mal, wenn Sie etwas mit True oder False vergleichen, einen Kommentar abzugeben.

2
Job

Eine solche Codierung hätte mich vorher auch falsch gerieben. Obwohl Ihre Beispielkennung "someBool" heißt, kann die unbeabsichtigte Verwendung dieses Codierungsstils für eine Variable, von der nicht garantiert wurde, dass sie ein Boolescher Wert ist, ein unbeabsichtigtes Verhalten aufweisen. 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 solche Konstrukte beschönigen. Sie würden denken: "Wie könnte es falsch sein?" Gleiches gilt für so gut verstandene Ausdrücke wie "(var)" oder "(! Var)", dass Sie sie lesen oder codieren, ohne ihr Verhalten zu überprüfen.

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

  1. Alle Ausdrücke müssen entsprechend ihrer Absicht in Klammern gesetzt werden.
  2. Alle booleschen Tests müssen negativ ausgedrückt werden, wie "suchBool! = False".

Durch das Bereinigen von Code, der nicht dem neuen Stil entspricht, habe ich einige weitere Fälle derart subtiler Fehler identifiziert und korrigiert.

1
Huperniketes

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 am besten, genau zu sein.

1
bburbank

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

Um einen weiteren Missbrauch von Booleschen Werten hinzuzufügen, habe ich diese Art von Konstruktion einige Male in Javascript gefunden (insbesondere bei einigen spaghettiähnlichen 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 aufgrund des Fehlens einer strengen Typdefinition in dieser Sprache es vorziehen, nicht mit den false|undefined - Werten herumspielen zu müssen.

1
Tomas Narros

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, also ändert er ihn in:

if(something == true && false)

Und dann ändert er es gelegentlich in:

if(false)

Das Schlimmste ist, diese Art des Debuggens hat mich gelegentlich verärgert und ist für andere Entwickler wirklich schlecht zu lesen!

1
ingh.am

Ich würde sagen, Konsistenz ist König in einer Codebasis. Sie sollten also den Stil verwenden, der meistens in Ihrer Organisation verwendet wird. Versuchen Sie, Ihren bevorzugten Stil in die offiziellen Richtlinien für die Unternehmenscodierung aufzunehmen. Wenn es bereits in den Richtlinien enthalten ist, befolgen Sie es einfach.

(Davon abgesehen würde es mich auch wirklich nerven - aber wahrscheinlich nicht genug, um eine große Sache daraus zu machen).

0
driis

Ich ziehe es vor, das Extra == true nicht zu platzieren, aber manchmal füge ich es versehentlich ein und bemerke es nicht. Die Person hat sie möglicherweise nicht bemerkt und versehentlich platziert. Ich lese meinen Code erneut und stelle manchmal fest, dass ich das Extra == true platziert habe, damit ich das == true entferne. Ich merke es manchmal nicht und würde gerne jemanden begrüßen, der mir sagt, dass ich es überflüssig platziert habe.

0
sange

Mein Kollege namens if a loop. Ich habe gelebt, um davon zu erzählen.

0

Man kann diese Angewohnheit entwickeln, wenn man viel in WPF programmiert. Es verwendet viel Bool? (nullable bool) Variablen müssen Sie entweder if (someBool == true) oder if (someBool ?? false) schreiben

0
Poma

Hoffentlich verwenden Sie eine sinnvolle Sprache wie VB.NET mit Option Strict On, die es nicht zulässt, dass andere Typen in einer If-Anweisung boolesch werden. Dann müssen Sie niemals "== true" (oder "= True" in VB) hinzufügen, da der Zwangsfall nicht auftreten kann. Wenn Sie nach Nicht-Null suchen möchten, schreiben Sie dies explizit (dh "Wenn x <> 0").

0
o. nate

wie wäre es mit:

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

Ja, ich habe es gesehen.

0
Dave

Es ist ein Code-Geruch für einen unerfahrenen Entwickler. Sie müssen die boolesche Bedingung noch beherrschen/verinnerlichen und müssen explizit die wahre oder falsche Bedingung bewerten.

0
Chuck Conway

In JavaScript bevorzuge ich if(bool), wenn ich genügend Dokumentation habe, um zu erklären, was die Methode erwartet ... aber wenn Auswertung von true bedeuten kann, dass die Variable existiert, entspricht sie der Zahl 1 oder dem Booleschen Wert Es stimmt, es ist härter.

Starkes Tippen in JS bedeutet auch weniger Flexibilität. Schwierige Wahl. Stark getippte Sprachen, leg den Hammer hin. Ansonsten fragen Sie, warum er es tut?

Eigentlich gibt es Ihre Antwort: Fragen Sie ihn warum. Dann korrigiere ihn.

0
Clint

nutzen Sie es als Gelegenheit, ihn zu unterrichten. Er wird dich mehr respektieren, wenn du es tust. Möchten Sie nicht, dass jemand dasselbe für Sie tut?

0
Rush Frisby

Untersuchungen zeigen, dass Code mit vielen Redundanzen stark mit Fehlern korreliert. Hier ist ein interessantes Papier zu diesem Thema (PDF-Warnung).

0
David Plumpton

Der Vergleich von Booleschen Werten kann tatsächlich zu großen Problemen führen. Ich bin kürzlich auf einen internen Code gestoßen, der lautete:

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

Das scheint ziemlich einfach zu sein, oder? Vereinfachen Sie es einfach auf:

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

Falsch. In diesem Fall schreibt die Reihenfolge der Operationen vor, dass && Zuerst ausgewertet wird, was bedeutet, dass dies wirklich wie folgt ausgewertet wird:

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

auch bekannt als

if(!foo)

Das Extra, nach dem wir suchen sollten, bar == 2, Ist völlig weg. Aus diesem Grund werde ich niemals eine Codeüberprüfung genehmigen, die someBool == [true|false] Enthält.

(Sie können sehen, wie die umgekehrte Anweisung == true Und || Auch Probleme verursachen würde.)

0
tghw

Ja, dies ist eine Art Denkweise für Programmierer. Die ganze Zeit über denken sie, dass "wenn Bedingung" keine Existenz ohne einen Ausdruck mit Symbolen hat =, <,> ... Ich habe Situationen gesehen, in denen Menschen wirklich kämpfen, wie "Funktionsrückgabe".

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

Programmierer müssen ihren Code aus dem Echtzeitwinkel betrachten .. :)

0

Ein Problem in C ist, dass es eine Tradition gibt, andere Werte als 0 und 1 für Boolesche Werte zu verwenden.

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

oder sich sogar darauf verlassen, dass -1 wahr ist.

Das Problem ist, dass Sie eine API schreiben:

struct foo { 
  unsigned int bar : 1;
};

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

Wenn der Balken nicht auf 0 oder 1 kanonisiert ist, passt er nicht in das Bitfeld und bricht:

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

Sie können auch andere Wege finden, wie nicht-kanonische Bools brechen, z. B. den Vergleich mit TRUE oder FALSE wie in der Frage!

Ich komme jedenfalls dazu, dass es oft Sinn macht, einen Bool zu kanonisieren:

foo->bar = bar != FALSE;

Dies ist natürlich eine C-spezifische Verrücktheit.

0
Havoc P

Ja, es ist eine große Sache, denn der Name des Booleschen Werts sollte sagen, dass es ein Boolescher Wert ist. Sagt, wenn Sie diesen Code haben:

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

Es ist bereits leicht zu lesen, sodass Sie == true Nicht benötigen, selbst für Personen oder Programmierer mit weniger Sinn für Bewertung.

0
tia

Programmierkonventionen sind nicht unbedingt "richtig" oder "falsch". Sie sind vorhanden, um den Lesern eine vertraute Struktur zu geben, damit mögliche Fehler deutlicher hervorgehoben werden. Es ist schwierig, ein Problem zu "erkennen", wenn für Sie alles etwas falsch aussieht.

Wichtig ist, dass die Konventionen von allen Teilnehmern klar definiert und vereinbart werden (auch wenn die Vereinbarung lautet "Ich stimme zu, diese Konvention zu verwenden, während ich hier arbeite" :), andernfalls schadet sie mehr als sie nützt.

Natürlich ist der besondere Fall, einen Booleschen Wert mit wahr zu vergleichen, einfach falsch und sollte unter allen Umständen vermieden werden. ;-);

0

Ich schreibe if (var == false), weil ich nach dem Schreiben von var keine Lust mehr habe, zurück zu gehen und zu schreiben! dahinter. Ich mag auch, wie == false es klarer macht.

Jedoch == wahr ist einfach komisch. Ich weiß nicht, ob es Sinn macht, eine große Sache zu machen. Ich würde es nicht tun, wenn er nicht andere dazu drängt, es zu verwenden oder es zu einem Codierungsstandard zu machen.

0
user2528

Sie können versuchen, sich mit dem folgenden Beispiel an Ihren Kollegen zu wenden:

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

Er sollte sagen, dass die == true ist redundant und sollte umgeschrieben werden als

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

schon seit x == 3 ist bereits ein boolescher Ausdruck.

Jetzt präsentiere ihm das someBool == true Beispiel, aber leicht umgeschrieben:

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

Da someBool im Vergleich zum vorherigen Beispiel bereits ein Boolescher Wert ist, sollte jetzt klar sein, dass == true ist auch in diesem Beispiel redundant. Daher sollte es wie folgt umgeschrieben werden:

if (someBool) {
    ...
}
0
gablin

Witzig, weil ich immer Code ersetze wie:

if(foo) {

Mit:

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

Aber ich habe diese Angewohnheit, weil der Code, mit dem ich gearbeitet habe, die meiste Zeit keine eindeutigen Variablennamen hatte.

0
mhitza

Dies kann einige Ihrer Nicker in einem Bündel bekommen.

Wir haben Erweiterungsmethoden für .IsTrue und .IsFalse für den Bool-Typ.

Also schreiben wir

if (someBool.IsTrue ())

-oder-

if (someBool.IsFalse ())

Ja! Und ich liebe sie. Beim Lesen von Code wird es mir nur offensichtlicher.

0
ElGringoGrande