用==赚大钱吗?


105

我的一位同事不断写道:

if (someBool == true)

它把我推高了!我应该大量使用还是仅丢弃它?


12
我更喜欢显式if (some_flag == true)但隐式的if (is_something)or if (has_something)。注意变量名。
fredoverflow

69
提醒您的同事,的类型someBool == true也是布尔值,因此按照同样的逻辑也应该是if ((someBool == true) == true)
Mike Seymour 2010年

2
@GSto:我想您知道这一点,但是在PHP中,您可以这样做以将任何内容“投射”到布尔中,并且实际上很有用。
zneak 2010年

2
@zneak或者您可以更清楚地使用它$var = (bool) some_expression。在大多数情况下,它甚至都没有关系,因为PHP将动态地进行必要的转换。
waiwai933

4
始终先检查常量,如果(true == someBool),以防万一您不小心键入了=而不是== [是,我在开玩笑!]
Steven A. Lowe,2010年

Answers:


126

这只是冗余代码,不是生与死。然而....

如果经常发生,someBool命名方式可能会出现问题。一个好名字可以大大消除对==true

if(IsSomeCondition)

要么

if(hasCondition)

要么

if(somethingExists)

例如。


这对我来说是最正确的。一切都与清晰度和命名技巧有关,原始语法还不错,但这是获得更好代码的正确途径。
TJB

2
击败我吧!如果没有适当的命名,那么更简洁的等效性将毫无意义。
Troy Hunt,2010年

4
someBool == true为了清楚起见,我不得不多次使用遗留代码。但是,如果我从头开始编写,我会相应地命名变量并使用if (isSomething)
nimcap 2010年

我同意,即使命名可以解决此问题,假设名称为SomeBool,它也可以表示任何含义,可以是任何类型(整数等于数组中布尔值的数量吗?)。布尔值需要某种存在性动词,否则它们将永远很难独自阅读。
Morgan Herlocker 2010年

我同意,这全都与可读性有关。如果变量命名正确,则不需要它。如果表达式可以更好地读取,我会选择“ == true”,如果您使用“ == false”而不是(丑陋的)“ if(!())”,这也是一致的。
罗尼·布伦德尔

71

当我看到时someBool == true,我禁不住觉得程序员还没有内化评估的想法,这是一个非常根本的缺陷。

但是,我的观点是歪斜的,因为我花了几个暑假在大学里为孩子们教授编程,他们之所以经常写这样的表达,是因为他们确实没有掌握评估表达的心理活动。一旦他们理解了这个概念,冗余就变得显而易见了。

对于其他有能力的专业程序员,情况可能并非如此。这可能只是他们在编程初期就养成的一种坏习惯,而且从来没有动摇过。但是,如果这是我在面试中看到某人所做的第一件事,仍然会令我有些恐惧。


我不会那么快就习惯这个。我从专业程序员的口中听到了一些真正令人震惊的事情。通常此后不久,便有一位古怪的人,“这怎么工作的?”
dash-tom-bang 2010年

12
完全同意评估。偶尔我想知道,“它在哪里停下来?” if(((((x == true)== true)== true)!= false)//等等...
yawmark 2010年

1
有时我会写if (c == true) return true; else return false;,但是有99%的时间(有1%的时间在那儿,因为我无法确定自己没有错过什么),我会立即注意到并用代替整个内容return c。我希望大多数有能力的程序员如果在职业生涯的早期就养成习惯,就应该做类似的事情。我不期望的是wtf响应。
Lie Ryan 2010年

1
哦,男孩,思考的艺术。我上周在我们的代码库中确实遇到了这个问题。if (!someCondition) { someCondition = false; }我已经在我们的代码中看到了一些(很多)冗余以及一些不可能,但是这个代码很简单,但是却以为有人真正写了它而使情况更糟。甚至多次。
安东尼·佩格拉姆

1
只是请注意,我已经看到一些情况if(x) x=true;不是多余的,而是等效于x=!!x;(将x归一化为0/1)
jkerian 2010年

58

这也使我发疯,但是我要说的是以建设性的方式向他们提及冗余,然后即使他们不同意也要放弃它。

或者,您可以尝试这种方法:
可以开始使用以下代码约定来评估布尔值吗?

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

他们:我们为什么要这样做?该语句的后半部分是多余的,它将始终为true。

您:乔治,您说得对。傻我 那么,我们就选择一个没有所有冗余的版本。怎么样?

if (someBool) {}

6
是的,同意。这很愚蠢,但是您必须选择打架,并且这段代码确实可以完成您的同事所做的一切。在非“提及您的情况到底是什么?!”中提及它。一种方式,然后将其删除。尽管如果他们开始拉垃圾一样:“如果(!someBool =真)”或“if(!someBool ==真)”或其他类似的卷积,这可能是一场值得采摘....
BlairHippo

3
(someBool == false)与if(someBool == true)有何不同?
FinnNk 2010年

5
true=true无法编译,您无法分配true;-)
fredoverflow

1
我已经习惯了if(somebool == false)!=,但是总是反对false和not true。我发现它是多余的,但是由于编码标准坚持认为if()看起来像一个函数调用,括号之间的空白有助于我阅读它。就我个人而言,布尔是布尔,但if (somePointer)不会飞;我更喜欢if (somePointer != NULL)因为指针不是一个布尔值。
dash-tom-bang 2010年

5
这是关于可读性,而不是非逻辑或(微)冗余
Ronny Brendel

45

我认为,如果琐事是您与同事之间最大的问题,那么您应该认为自己很幸运。


5
好吧,它是追求完美的好地方,但是肯定有更大的鱼可以炸
TJB

3
我认为您是在谈论每个值得讨论的问题的。
Dave Van den Eynde

2
这可能预示着更大的问题。车库天花板上的一小块棕色污渍似乎没什么大不了的,但这可能意味着您漏水严重。
乔什(Josh)

42

您绝对应该停止这种不良习惯。轻轻地...

很容易忘记编写双等号,将代码转换为:

if (someBool = true)

例如,在C#中,这只会产生警告,而不是错误。因此,除非将警告视为错误,否则代码将运行,请将变量设置为true并始终输入条件。


6
这不是一个相关的论点。如果您使用的是这样的语言,则可以将true移到另一侧。问题是是否要包含真实值。
凸轮

8
@Cam:你错过了重点。我不建议使用后向逻辑。
古法

15
@Cam-他提供了一个实际的例子,说明何时可能会出现问题。我会说这很相关。
ChaosPandion 2010年

1
@Guffa Cam非常正确。这不是停止在if块中使用==(anyType)的原因。
罗尼·布伦德尔

2
@Ronny:不,任何类型都不可能发生(除非语言实际上允许任何类型作为条件)。该语句if (answer = 42) {}根本无法编译,因为该表达式不是布尔值。
古法

21

我同意你的观点,但是我将在这里扮演魔鬼的拥护者:


根据语言和变量的名称,x == true是合适的:

请考虑以下情况,这种语言具有静态类型和整数类型的类型强制:

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

读完本节代码的人可能不会立即意识到actionsAllowed是一个布尔变量-它也可以是整数,表示允许的操作数。因此,通过添加== true,可以清楚地看到x是一个布尔值,而不是强制转换为布尔值的整数:

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

13
可读性==良好
Muad'Dib 2010年

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

1
bool isGoodThing =可读性?true :(编码标准?true:(internalizationOfConcept?true:false));
johnc

17
所以重命名变量actionsAreAllowed
Graeme Perrow

9
通过编写,if (x) { ...您已经在断言它x是布尔值还是可以转换为布尔值。您所说的与您无关。
Daniel Earwicker 2010年

15

那可空布尔呢?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

如果(MyFlag.Value)
johnc

1
并非所有语言都具有可为空的布尔,并且许多这样做的语言都会接受您的第二种构造。
zneak 2010年

1
@johnc:“ if(MyFlag.Value)”可能并没有真正做到您想要的,因为如果MyFlag为null(可以通过检查MyFlag.HasValue进行测试),它可能会引发异常。
Ludovic Chabant 2010年

4
这是我的带有可空布尔值的小表情:)
Jarrod Dixon

3
布尔?isValid = null; if(isValid ?? false);
skolima 2010年

11

通常,您不希望在编码约定上花很多钱,除非所述约定在某种程度上严重阻碍了项目。我已经看到许多激烈的争论在诸如代码区域和下划线之类的小问题上升级。

话虽如此,我认为添加== true条件语句没有问题。实际上,== false在测试负面条件时,我习惯于使用而不是领先的感叹号。我认为它更具可读性。

如果有既定的约定,除非有理由更改,否则请遵循。但是,真正值得一提的是。


1
根据您的语言,即使someValue评估为true,也不一定等于true。例如,(9 == True)在Python中评估为false,我可以想象在C ++中也是如此。
dash-tom-bang 2010年

代码区域和下划线使我想打人。
MGOwen

11

阿克 我就是那个人 可耻,可耻。这就是我的学习方式,也是我头脑中的“自动格式化”方式。我唯一一次使用Joel的首选语法是当bool变量的动词前缀为“ is”时。我需要动词,例如“是”,“可以”,“已完成”,否则我需要==提供动词“等于”。我可能永远不会改掉这个习惯,所以如果您在街上不跟我打招呼,我会明白的。


7
这不是一件坏事。像真实文本一样阅读的代码要比隐式foo好得多。为了便于阅读,请养成该习惯。
罗尼·布伦德尔

11

让我想起“布尔疯狂代码”,就像这样

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

代替:

 otherBool = !someBool

这很有趣,我必须维护一个系统,这些系统到处都是垃圾。它使我发疯。
Tjaart

8

就我个人而言,我非常不喜欢基于C的语言说“不”的方式。那个小小的感叹号太容易忽略了。

因此,我将其完整写出:

if (someCondition == false) {

看了一段时间后,我也想对称

if (someCondition == true) {

因此,请考虑使用C !代替not


3
C ++实际上具有not运营商,也是如此C(一旦你包含标准头<iso646.h>)。如果您不想(或不能)使用此标头(或者您被Java或C#所卡住),建议您在感叹号后添加一个空格:if (! condition)。这使它更加显眼。
康拉德·鲁道夫

1
我会做Java。 not不是一个选择。

6

这取决于语言,但这通常是个坏主意...

在C语言中,绝对不要这样做。很容易发现您要测试的值不是false(非零),但也不等于定义为“ true”的单个值的情况。

在Ruby中,仅当您完全确定要对除Boolean true以外的所有内容都失败时,才执行此操作。

在具有bool类型的C ++和其他静态语言中,它是多余的,并且在您键入错误=而不是时可能导致编程错误==,或者引起注释中提到的升级错误。


实际上,在赋值运算符返回值的语言中(例如C ++ if (b == true) {),不仅是多余的。这也有些冒险,因为您可能不小心将分配trueb
斯蒂芬·C

4
这不仅在C ++中是多余的,而且很危险。如果你写的if (b == true),而b不是一个布尔值,类型转换的走错路。A bool是一个整数类型,通常会提升为带有值1的适当整数类型。如果您说,例如,int b(2); if (b == true)然后为了比较的目的而true变成一个int带有值1的a,而不是b被强制为type bool,这将给出正确的结果。
David Thornley,2010年

@DavidThornley,在编译器中打开警告。将警告视为错误是一种更好的防御性编程技术,而不是避免使用==
Abyx 2011年

5

你以为不好吗 怎么样:

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

2
男孩,我已经看过多少次了。对于像ReSharper这样的工具,这是一个很好的例子。
Job

是的-如果您租用土块,请购买ReSharper。
柯克·布罗德赫斯特

4

我更喜欢

if (bVal)

要么

if (!bVal)

也有,但是我担心提出来会使人们生气,所以我的建议是忘记它。抱歉!


4
对于所有的爱是神圣的,只要它没有 if (!bNotVal)if (bNotVal)甚至在首位。名称中的否定词使所有内容都难以阅读。
dash-tom-bang 2010年

2
我知道一个开发人员会宣布isNotConnected;如果(isNotConnected ==真)......呸
johnc

4

你应该告诉他他做错了。

它的

如果(true == someBool){

}

如果他忘记了一个=他的写作风格会遇到很大麻烦。


3

怎么样

if (x == "true")

为什么是一个字符串?


我正在处理一些遗留的php代码,有时会发现类似的东西if(preg_match('/title/', implode($_POST))){。PHP,足够说了,我需要找到更好的工作。
Keyo 2010年

4
是的,我也查看是否(x ==“ 1”),但这通常是针对较差的数据库设计。
atfergs 2010年

x来自用户输入(例如配置文件或Web服务)时,我使用了类似的构造。但是,我通常允许使用其他值,所以最终结果更像是if x.lower().strip() in ["true", "yes", "on", "1"]
eswald,2010年


3

我写这样的代码!

原因如下:

“ if bla == true”的读起来像一个句子,而“ if bla”在很多情况下都不是。在读取实际代码时,这听起来似乎是错误的。

编译器还会警告if块中的分配,因此使用== true确实没有危险。(将其与=混淆)

那些不写“ == true”的人还会用“!()”代替“ == false”吗?我觉得这很丑。而且,如果您使用“ == false”,则仅使用“ == true”也是非常一致的,而不是采用两种不同的方式来验证真相。


3
您说的“ if bla”读起来不像句子……这意味着您的变量命名不正确……这是怎么回事:if(userHasRights)doSomething()
JoelFan 2010年

“在许多情况下”。是的,你是对的。重命名也可以。使用“ if(QWidget :: acceptDrops()== true)”,您将无法重命名。也许将它命名为dosAcceptDrops()可能会很好。。。这太麻烦了(并且不可能在任何API中使用该省略规则来保持一致),因此要与其他“ == what” -ifs保持一致,我强烈建议您不要忽略它,这样它就不会“看起来”有所不同,因此看起来是一致的。
罗尼·布伦德尔

3

请记住,您是团队的一部分,因此您需要一起解决这些问题。即使在上小学后,“与人和睦相处”仍然是一个重要的人格特质:)


2

通常会忽略“ == true”,但是,除非您将其包含在团队的编码标准中,否则即使讨论一分钟也几乎不值得。


3
另外,如果它属于团队的编码标准,那么您确实需要重新评估这些标准,以消除这种琐事。
JohnFx

同意!以防万一...
FinnNk 2010年

2

尽管我以主要的C#开发人员的身份同意,但我不能总是这样。例如,在Javascript中,===将执行类型合并。因此,假设var x = 3,则:

if(x) --> true

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

我想这与==不同,因为即使在JS中,我也不会使用if(x == true),而只是要考虑一下。

我办公室的另一点是这样的:

bool b = false;

在C#中,布尔b; 就足够了,并且会使b变为false。但是,更明确的是编写上述行,并且无论如何在优化过程中编译器都应将其删除。

因此,我想我的意思是,什么是好方法,哪些不是好方法并不总是那么明显,很多归结为偏好以及语言功能/怪癖。


bool b;仅在b为字段时才初始化为false 。您必须显式初始化局部变量。
马修·弗拉申

+1同意。其他(脚本)语言也存在相同的问题。如果要测试布尔值true或仅测试“ true”,则必须明确。例如,即考虑任何非空字符串,== true但不考虑=== true某些语言。
Martin Wickman

2

是的,但是如果变量可以为空,该怎么办?(布尔?)

某些语言(C#)将要求使用强制转换或与“ true”进行比较。

bool? isAccepted = true;

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

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

2

年轻的人知道规则,老的人知道例外;)

最近C#,如果您要处理null-able bool,则必须:

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

如果tristate没问题,那么通常不应该将理由与true/ 进行比较True。但是,在Python以及其他几种语言中,C/C++您可以if对非布尔表达式执行。这些语言具有用于将整数,指针,列表等解释为true或false的独特规则。有时候你不想要那样。例如,在以下Python代码段中:

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

这里z应该True,但是z2应该False。现在,一种Clojure语言以另一种方式解决了这一问题- and函数不一定要求值为bool,而是if可以处理。

无论使用哪种语言,只要您发现自己与True或进行比较False,就可能值得一提。


第一个问题源于使用糟糕的变量名导致的错误前提IMO。假设X,Y,Z分别命名为notExceptButHasXexceptNotButIsntYdoNotUnlessIsExceptZ?这如何使您的问题更具可读性?如果x,y,z被命名为“ isEnabled”,“ isEffective”,“ hasProperty”,则您的语句变得isEnabled || isEffective || hasProperty比与true或更具可读性false
Thomas

1

这样的编码以前也将以错误的方式抚慰我。尽管示例标识符的名称为“ someBool”,但在不能保证为布尔值的变量上无意中使用该编码样式可能会导致意外的行为。如果“ someBool”的值不完全是“ true”或“ false”,则结果将为false。

去年,我遇到了一个非常细微的错误,它是由这种编码风格引起的,由于人的眼睛在这种结构上蒙上了一层眼睛,所以很难识别。您可能会想:“怎么可能错了?” 对于诸如“(var)”或“(!var)”之类的易于理解的表达式,您在不验证其行为的情况下对其进行读取或编码也是如此。

因此,我引入了一些编码标准,以减少代码库中此类错误的存在,以及减少此类细微错误在将来某个时候意外蔓延的可能性。

  1. 必须根据意图将所有表达式括在括号中。
  2. 所有布尔测试必须以否定形式表示,例如“ suchBool!= false”。

通过清理不符合新样式的代码,我确定并纠正了一些此类细微错误的实例。


1
使someBool成为TRUE / FALSE以外的东西是不好的编码习惯。
AttackingHobo 2010年

@AttackingHobo,这是没有语言中的布尔类型和/或不使用类来提供所需的确切行为的陷阱之一。
Huperniketes

1

必须在ActionScript 2中一直使用它(现在已经成为一种死语言),因为:

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

因此,几乎总是最好要具体。


1

我同意。这是多余的结构,特别是在强类型语言中。

为了进一步滥用布尔值,我在Javascript中多次发现了这种构造(特别是在类似意大利面条的怪兽函数中,如100多个行):

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

似乎由于该语言缺乏严格的类型定义,因此某些程序员希望不必弄乱这些false|undefined值。


1

我有一个同事,他将有一些这样的代码:

if(something == true)

然后,对于某种测试/调试,他希望不调用此块,因此将其更改为:

if(something == true && false)

然后偶尔他会将其更改为:

if(false)

最糟糕的是,这种类型的调试有时会困扰我,对其他开发人员而言,这确实很糟糕!


0

我想说一致性是代码库中的王者。因此,您应该使用组织中常用的样式。尝试使您偏爱的样式成为官方公司编码准则的一部分。如果已经在指南中,请遵循它。

(话虽如此,这也确实使我烦恼-但可能不足以使事情大为改观)。


0

我更喜欢不放置多余的== true,但有时我不小心包含了它,却没有注意到它。该人可能没有注意到并意外放置它们。我重读了代码,有时会注意到我放置了额外的== true,所以我删除了== true。有时我没有注意到它,会很乐意欢迎有人告诉我我多余地放置了它。


0

怎么样:

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

是的,我已经看过了。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.