用==赚大钱吗？

我的一位同事不断写道：

if (someBool == true)

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

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

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

if(IsSomeCondition)

要么

if(hasCondition)

要么

if(somethingExists)

例如。

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

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

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

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

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

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

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

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

if (someBool) {}

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

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

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

if (someBool = true)

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

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

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

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

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

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

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

那可空布尔呢？

bool? MyFlag = null;

if (MyFlag == true)
    ;  

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

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

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

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

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

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

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

代替：

 otherBool = !someBool

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

因此，我将其完整写出：

if (someCondition == false) {

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

if (someCondition == true) {

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

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

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

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

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

你以为不好吗 怎么样：

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

我更喜欢

if (bVal)

要么

if (!bVal)

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

你应该告诉他他做错了。

它的

如果（true == someBool）{

}

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

怎么样

if (x == "true")

为什么是一个字符串？

实际上，如果可以为空，则必须测试x == true。:)

我写这样的代码！

原因如下：

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

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

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

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

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

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

if(x) --> true

而

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

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

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

bool b = false;

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

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

是的，但是如果变量可以为空，该怎么办？（布尔？）

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

bool? isAccepted = true;

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

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

年轻的人知道规则，老的人知道例外；）

最近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，就可能值得一提。

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

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

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

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

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

必须在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)
{
}

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

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

为了进一步滥用布尔值，我在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值。

我有一个同事，他将有一些这样的代码：

if(something == true)

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

if(something == true && false)

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

if(false)

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

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

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

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

怎么样：

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

是的，我已经看过了。