it-swarm-eu.dev

Udělejte hodně z == pravda?

Můj kolega neustále píše:

if (someBool == true)

To mě přivádí ke zdi! Měl bych to udělat hodně nebo to prostě nechat?

105
JoelFan

Je to jen nadbytečný kód, nikoli život nebo smrt. Nicméně....

Pokud se to hodně děje, může to být problém s tím, jak se jmenuje someBool. Dobré jméno může jít dlouhou cestou k eliminaci potřeby ==true

if(IsSomeCondition)

nebo

if(hasCondition)

nebo

if(somethingExists)

například.

126
Robert Harvey

Když vidím someBool == true, Nemůžu si pomoct, ale mám pocit, že programátor internalizoval myšlenku vyhodnocení, což je docela zásadní nedostatek.

Moje perspektiva je však zkreslená, protože jsem několik let strávil v programování na vysoké škole pro děti, které často psaly výrazy, jako je tento, protože skutečně nezvládly mentální cvičení hodnocení výrazu. Jakmile tento koncept propadli, stalo se zbytečné.

U jinak kompetentního profesionálního programátora tomu tak pravděpodobně není. Je to pravděpodobně jen špatný zvyk, který vyvinuli ve svých počátečních dnech programování, a nikdy se úplně netřásli. Ale to by mě trochu vyděsilo, kdyby to bylo první, co jsem viděl někoho dělat v rozhovoru.

71
Tim Goodman

To mě taky nutí bláznit, ale řekl bych, že je konstruktivně zmiňuji o nadbytečnosti, a pak to upustím, i když se neshodují.

Alternativně byste mohli vyzkoušet tento přístup:
Vy: Můžete začít používat následující konvenci kódů pro vyhodnocení Booleovců?

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

Them: Proč bychom to udělali? Druhá polovina tohoto tvrzení je nadbytečná, vždy by se vyhodnotila jako pravdivá.

Ty: George, máš pravdu. Já hlupák. Pojďme prostě jít s verzí bez zbytečné redundance. Co takhle?

if (someBool) {}
58
JohnFx

Myslím, že pokud je něco tak triviálního vaším největším problémem se svými spolupracovníky, měli byste se považovat za hodně štěstí.

45
GrandmasterB

Určitě byste měli zastavit tento špatný zvyk. Jemně...

Je snadné zapomenout napsat dvojitá stejná znaménka a změnit kód na:

if (someBool = true)

Například v C # to vytvoří pouze varování, nikoli chybu. Pokud tedy nebudete s výstrahami zacházet jako s chybami, které se spustí, nastavte proměnnou na true a vždy zadejte podmínku.

42
Guffa

Souhlasím s vámi, ale budu hrát ďáblova obhájce zde:


V závislosti na jazyce a názvu proměnné je vhodné x == true:

Zvažte následující situaci v jazyce se statickým psaním a donucením typu u integrálních typů:

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

Někdo, kdo si přečte tuto část kódu, si nemusí okamžitě uvědomit, že actionsAllowed je booleovská proměnná - může to být také celé číslo představující počet povolených akcí. Přidáním == true se tedy vyjasní, že x je booleovský a ne celé číslo vynucené k booleovskému:

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

A co nullable bools?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

Obvykle nechcete dělat mnoho z konvencí kódování, pokud uvedená úmluva nějakým způsobem projekt nezpůsobí. Viděl jsem mnoho vyhaslých argumentů, které eskalovaly nad tak malými, jako jsou kódové oblasti a vedoucí podtržítka.

Jak už bylo řečeno, nevidím žádný problém s přidáním == true k podmíněnému příkazu. Ve skutečnosti mám ve zvyku používat == false na rozdíl od předního vykřičníku při testování na negativní podmínky. Myslím, že je to čitelnější.

Pokud existuje zavedená konvence, říkám ji následovat, pokud není důvod změnit. Nicméně, to opravdu stojí za to zvýšit velký smrad.

11
Casey

Ack. Jsem ten chlap. Hanba, hanba. Je to, jak jsem se naučil, a tak jsem se „autoformátoval“ v hlavě. Jediný čas, kdy používám preferovanou syntaxi Joela, je, když proměnná bool má předponu slovesa jako „is“. Potřebuji sloveso, ať už je „je“, „může“, „udělal“ nebo jinak potřebuji ==, abych poskytl sloveso „rovná se“. Tento zvyk nikdy nebudu porušovat, takže pochopím, jestli mi na ulici neřekneš „ahoj“.

11
Scott Fletcher

připomenout mi „booleovský kód šílenství“, jako je tento

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

Namísto:

 otherBool = !someBool
11
Marcelo de Aguiar

Osobně se mi moc nelíbí způsob, jak říci „ne“ v jazycích založených na C. Tento malý vykřičník je příliš snadné přehlédnout.

Proto jsem to napsat v plném rozsahu:

if (someCondition == false) {

Po přečtení, že na chvíli, chci také symetrii s

if (someCondition == true) {

Takže to považujte za artefakt C pomocí ! místo not.

8
user1249

Závisí to na jazyce, ale obvykle je to špatný nápad ...

V C, nikdy to udělejte. Je příliš snadné najít situaci, kdy testovaná hodnota není nepravdivá (nenulová), ale také se nerovná jedné hodnotě definované jako „true“.

V Ruby to udělejte, pouze pokud jste si naprosto jistí, že chcete selhat ve všem kromě Booleovské pravdy.

V C++ a dalších statických jazycích s typem bool je nadbytečný a může vést k chybám programování, když chybně zadáte = namísto == nebo chyby propagace, jak je uvedeno v komentářích.

6
AShelly

Myslíš si, že je to špatné? Co takhle:

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

Preferuji

if (bVal)

nebo

if (!bVal)

taky, ale obávám se, že to, že by se to vynořilo, by lidi štvalo, takže moje rada je na to zapomenout. Promiňte!

4
grokus

měli byste mu říct, že to dělá špatně.

své

if (true == someBool) {

}

pokud někdy zapomene na jeden = má ve svém psacím stylu velké potíže.

4
Display Name

Co takhle

if (x == "true")

PROČ IS ŽE STRING ?!

3
atfergs

Ve skutečnosti, pokud je to nulovatelné, bude nutné testování na x == true. :)

3
Matt Sherman

Takhle píšu kód!

Zde je proč:

"if bla == true" zní jako věta, kde jako "if bla" v mnoha případech ne. Při čtení skutečného kódu to prostě zní špatně.

Také kompilátor varuje před přiřazením v blocích if, takže při použití == true není opravdu žádné nebezpečí. (zaměňovat to s =)

Také chlapi, kteří nenapsají „== true“, použijte „! ()“ Pro „== false“? Považuji to za opravdu ošklivé. A pokud použijete „== false“, je pouze velmi konzistentní použít také „== true“, namísto dvou odlišných způsobů ověření pravdy.

3
Ronny Brendel

Pamatujte, že pracujete jako součást týmu, takže je třeba tyto věci vyřešit společně. „Hraje pěkně s ostatními“ je stále důležitým rysem osobnosti i po základní škole :)

3
cdkMoose

Obecně bude vynechána '== true', ale sotva stojí za to ani minutu diskutovat o ní, pokud ji nemáte zahrnut do standardů kódování vašeho týmu.

2
FinnNk

I když souhlasím jako hlavně C # vývojář, nemohu říci, že je to vždy tak. Například v Javascriptu === provede typovou koalescenci. Takže za předpokladu var x = pak:

if(x) --> true

zatímco

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

Myslím, že je to jiné než ==, protože ani v JS bych nepoužíval pokud (x == true), ale jen něco, o čem přemýšlet.

Tento druh dotýká se v jiném bodě, který se však objevil v mé kanceláři:

bool b = false;

V C # by bool b; stačilo a inicializovalo by b na false. Je však explicitnější napsat výše uvedený řádek a kompilátor by měl být během optimalizace roztrhán.

Myslím, že můj názor je, že to není vždy tak zřejmé, co je a není dobrá praxe, a mnoho z toho se scvrkává na preference a jazykové funkce/vtípky.

2
statichippo

Aha ano, ale co když je proměnná zrušitelná? (bool?)

Některé jazyky (C #) budou vyžadovat a obsazení nebo porovnání s 'true'.

bool? isAccepted = true;

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

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

Mládež zná pravidla, ale staré znají výjimky;)

Nejnovější C#, pokud jednáte s null-able bool, pak musíte:

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

Pokud tristát není problém, pak by obvykle neměl být důvod něco srovnávat s true/True. V Python a několika dalších jazycích, například C/C++ můžete provést if na výrazu bez bool. Tyto jazyky mají jedinečná pravidla pro interpretaci celých čísel, ukazatelů, seznamů atd. Jako pravdivých nebo nepravdivých. Někdy to nechcete. Například v tomto fragmentu Python):

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

Zde by z mělo být True, ale z2 by mělo být False. Nyní k tomu přistupuje jazyk Clojure ještě jiným způsobem - funkce and nemusí být nutně vyhodnocena jako bool, ale if to zvládne.

Bez ohledu na jazyk, kdykoli se ocitnete v porovnání s True nebo False, pravděpodobně stojí za to komentovat.

2
Job

Takovéto kódování by mě předtím také špatně otřelo. Ačkoli je váš příklad identifikátoru pojmenován „someBool“, použití tohoto stylu kódování neúmyslně na proměnné, u které nebylo zaručeno, že bude booleovský, může mít nezamýšlené chování. Pokud hodnota „someBool“ není přesně „true“ nebo „false“, bude výsledek nepravdivý.

Minulý rok jsem se setkal s velmi jemnou chybou způsobenou takovým stylem kódování, který bylo obtížné identifikovat, protože něčí oči takové konstrukty leskly. Mysleli byste si: „Jak by to mohlo být špatně?“ Totéž platí pro tak dobře srozumitelné výrazy jako „(var)“ nebo „(! Var)“, že je čtete nebo kódujete bez ověření jejich chování.

Takže jsem zavedl několik kódovacích standardů, abych snížil existenci takových chyb v kodebázi a pravděpodobnost, že se tyto drobné chyby náhodou vkradnou někdy v budoucnu.

  1. Všechny výrazy musí být podle svého záměru parentifikovány.
  2. Všechny booleovské testy musí být vyjádřeny negativně, například „suchBool! = False“.

Vyčištěním kódu, který neodpovídá novému stylu, jsem identifikoval a opravil několik dalších takovýchto drobných chyb.

1
Huperniketes

Musel to používat v ActionScript 2 po celou dobu (je to nyní mrtvý jazyk), protože:

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

Takže bylo téměř vždy nejlepší být konkrétní.

1
bburbank

Souhlasím. Je to nadbytečná konstrukce, zvláště v silně psaných jazycích.

Abych přidal další zneužití booleovců, našel jsem tento druh konstrukce v Javascriptu spoustu časů (zvláště u některých funkcí monster typu špaget, jako u 100+ řádků):

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

Zdá se, že kvůli nedostatku přísné definice typu v tomto jazyce, někteří programátoři raději nemusí pohrávat s false|undefined hodnot.

1
Tomas Narros

Mám kolegu, který bude mít nějaký takový kód:

if(something == true)

A pak, pro nějaký druh testu/debugování, bude chtít tento blok nevolat, takže ho změní na:

if(something == true && false)

A pak to občas změní na:

if(false)

Nejhorší na tom je, že tento typ ladění se mi občas otřel a je pro ostatní vývojáře opravdu špatný číst!

1
ingh.am

Řekl bych, že konzistence je král v kódové základně. Měli byste tedy použít styl, který se ve vaší organizaci používá většino. Zkuste, aby se váš preferovaný styl stal součástí oficiálních pokynů společnosti pro kódování. Pokud je to již v pokynech, postupujte podle něj.

(Jak už bylo řečeno, také by mě to opravdu otravovalo - ale pravděpodobně to nestačí na to, abych z toho vydělal hodně).

0
driis

Raději neuložím extra == true, ale někdy ho náhodou zahrnu a nevšímám si ho. Osoba si toho možná nevšimla a náhodně je umístila. Znovu jsem si přečetl svůj kód a někdy jsem si všiml, že jsem dal extra == true, takže jsem to == true odstranil. Někdy si toho nevšímám a ráda bych přivítala někoho, kdo mi řekl, že jsem ho dal zbytečně.

0
sange

Můj kolega s názvem if a loop. Žil jsem o tom vyprávět.

0
Daniel Mošmondor

Jeden zvyk může rozvíjet tento zvyk, když hodně programování v WPF. Používá hodně bool? (nullable bool) musíte zapsat buď if (someBool == true) nebo if (someBool ?? false)

0
Poma

Doufejme, že používáte rozumný jazyk, jako je VB.NET s Option Strict On, který neumožňuje donucení jiných typů k Boolean uvnitř příkazu If. Pak už není třeba nikdy přidávat „== true“ (nebo „= True“ ve VB), protože případ nátlaku se nemůže stát. Pokud chcete zkontrolovat nenulovou hodnotu, napište to explicitně (tj. „Pokud x <> 0“).

0
o. nate

co takhle:

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

Jo, viděl jsem to.

0
Dave

Je to vůně kódu pro začínajícího vývojáře. Ještě musí zvládnout/internalizovat booleovský stav a musí výslovně vyhodnotit skutečný nebo nepravdivý stav.

0
Chuck Conway

V JavaScriptu dávám přednost if(bool), když mám dostatečnou dokumentaci vysvětlující, co metoda očekává ... ale když vyhodnocení true může znamenat, že proměnná existuje, rovná se číslu 1 nebo booleovské pravda, je to tvrdší.

Silné psaní v JS také znamená menší flexibilitu. Tvrdé volání. Silně napsané jazyky položte kladivo. Jinak se zeptejte, proč to dělá?

Ve skutečnosti je tu vaše odpověď: zeptejte se ho proč. Pak ho opravte.

0
Clint

využijte ji jako příležitost jej naučit. pokud ano, bude vás více respektovat. nechtěl byste, aby vám někdo udělal to samé?

0
Rush Frisby

Výzkum ukazuje, že kód s mnoha propouštěními silně koreluje s chybami. Zde je zajímavý článek o záležitosti (upozornění PDF).

0
David Plumpton

Porovnání booleovců může ve skutečnosti způsobit velké problémy. Nedávno jsem narazil na nějaký interní kód, který četl:

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

Teď se to zdá docela rovně, že? Jednoduše to zjednodušte na:

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

Špatně. V tomto případě pořadí operací diktuje, že && získá první hodnocení, což znamená, že se to opravdu vyhodnotí takto:

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

také známý jako

if(!foo)

Ta další věc, kterou jsme měli kontrolovat, bar == 2, je úplně pryč. Proto nikdy nikdy neschválím kontrolu kódu, která obsahuje someBool == [true|false].

(Můžete vidět, jak se reverzní příkaz, == true a ||, také by to způsobilo problémy.)

0
tghw

Ano, toto je druh programátorské mysli. Po celou dobu, co považují za „pokud podmínka“ neexistuje, bez výrazu se symboly =, <,> ... Viděl jsem situace, kdy lidé opravdu bojují jako „návrat funkce“

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

Programátoři musí sledovat svůj kód z úhlu reálného času .. :)

0
Krishna Prasad A

Jeden problém v C je, že existuje tradice používání hodnot jiných než 0 a 1 pro booleovské hodnoty.

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

nebo dokonce spoléháme na to, že -1 je pravda.

Problém je v tom, že píšete API:

struct foo { 
  unsigned int bar : 1;
};

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

Pokud zde bar není kanonikalizován na 0 nebo 1, nezapadne na bitové pole a zlomí se:

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

Můžete najít i jiné způsoby, jak se kanonické boole rozbijí, například jejich porovnání s TRUE nebo FALSE jako v otázce!

Každopádně se chystám obejít, že často má smysl kanonikalizovat bool:

foo->bar = bar != FALSE;

Toto je samozřejmě zvláštní podivnost.

0
Havoc P

Ano, je to velký problém, protože název booleovského čísla by měl říci, že je booleovský. Říká, že máte tento kus kódu:

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

Čtení je snadné, takže nebudete potřebovat == true, a to i pro osobu nebo programátora s menším smyslem pro hodnocení.

0
tia

Programovací konvence nemusí být nutně „správné“ nebo „špatné“. Existují, aby těm, kdo si jej přečetli, dali programu známou strukturu, takže případné chyby budou jasnější - je obtížné problém „vidět“, pokud vás všechno trochu špatně hledá.

Důležité je, aby byly všechny úmluvy jasně definovány a odsouhlaseny všemi účastníky (i když dohoda je jako „Souhlasím s používáním této úmluvy, když zde pracuji“ :), jinak to způsobí více škody než užitku.

Obzvláště případ porovnání booleovské hodnoty s pravdou je samozřejmě nesprávný a za každou cenu je třeba se mu vyhnout. ;-)

0
Daniel C. Sobral

Píšu, pokud (var == false), protože po psaní var se mi nebude líbit zpětné psaní a psaní! za tím. Také se mi líbí, jak == false umožňuje vypadat jasněji.

Nicméně == true je prostě divný. Nevím, jestli má smysl něco udělat. Já bych nechtěl, pokud tlačí ostatní, aby to používali nebo aby z něj udělali kódovací standard.

0
user2528

Můžete zkusit kontaktovat svého kolegu pomocí následujícího příkladu:

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

Měl by říci, že == true Je nadbytečný a měl by být přepsán jako

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

protože x == 3 je již booleovským výrazem.

Nyní mu představte příklad someBool == true, Ale mírně přepsaný:

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

Protože someBool je již booleovský, ve srovnání s předchozím příkladem by nyní mělo být jasné, že == true Je v tomto příkladu také nadbytečný. Proto by mělo být přepsáno takto:

if (someBool) {
    ...
}
0
gablin

Legrační, protože vždy nahrazuji kód jako:

if(foo) {

S:

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

Tento zvyk jsem však získal, protože kód, se kterým jsem pracoval, neměl většinou jasná názvy proměnných.

0
mhitza

To může dostat některé z vašich přezdívek v bahně.

Máme metody rozšíření pro .IsTrue a .IsFalse pro typ bool.

Takže píšeme

if (someBool.IsTrue ())

-nebo-

if (someBool.IsFalse ())

Ano! A já je miluji. Při čtení kódu je to pro mě více zřejmé.

0
ElGringoGrande