为什么在布尔值变量上使用！boolean_variable == false

关于此问题的评论：检查方法是否返回false：将结果分配给临时变量，还是将方法调用直接置于条件中？说应该在测试条件时使用!boolean而不是boolean == false。为什么？对我boolean == false来说，英语更加自然，也更加露骨。抱歉，这仅是风格问题，但我想知道是否还有其他原因导致这种偏好!boolean？

当我看到这样的一行时 if (!lateForMeeting())，我将其读为“如果不迟到开会”，这很容易理解，而if (lateForMeeting() == false)我读为“如果我迟到开会的事实是错误的” “。

它们的含义相同，但是前者更接近于构造等效的英语句子的方式。

写作== false和== true是多余的。它也可以被带到任意的极端。如果你开始写作

if (condition == false) { ... }

那为什么不

if ((condition == false) == true) { ... }

还是为什么不

if ((someExp == anotherExp) == true) { ... }

这个故事的寓意是，如果condition是布尔表达式，则无需添加== false；这就是运算符!的作用;）

在C语言和某些类似语言中，比较布尔表达式是否等于false或true具有危险习惯。

在C语言中，任何标量表达式（数字或指针）都可以在布尔上下文中使用，例如，作为if语句的条件。C规则if (cond)等效于if (cond != 0)-即零为false，任何非零值为true。如果cond是指针类型，则将其0视为空指针常量；否则为false。if (ptr)意味着if (ptr != NULL)。

这意味着

if (cond)

和

if (cond == true)

没什么意思。如果cond非零，则第一个为true；否则为false 。第二个只有在等于时才是正确的true，在C中（如果有的话#include <stdbool.h>）就是1。

例如，如果参数为数字，则isdigit()in中声明的函数<ctype.h>将返回一个int值，0否则为非零。它可以返回42以表明条件为真。比较42 == true将失败。

碰巧这0是唯一被认为是错误的值，因此比较是否相等false将起作用。if (!cond)并if (cond == false)做同样的事情。但是，如果要利用这一点，则必须记住，与进行比较false是可以的，而与进行比较是不可行的true。更糟糕的是，相比true将工作的大部分时间（例如，平等，关系运算符总是产生两种0或1）。这意味着使用此工具引入的任何错误仍然可能很难找到。（不用担心，一旦您将代码演示给重要的客户，它们就会出现。）

C ++的规则略有不同。例如，其bool类型与语言紧密集成在一起，并if (cond)转换cond为type bool。但是效果（大部分）是相同的。

其他一些语言具有所谓的行为更佳的布尔值，因此cond == true和cond == false（或任何语法碰巧）都是安全的。即使这样，我见过的每种语言都有一个notor !运算符；它在那里，所以您不妨使用它。使用cond == false而不是!cond或not cond不，在我看来，提高可读性。（确实，!角色一目了然很难看到；!为避免这种情况，我有时会在其后添加一个空格。）

通常，您可以通过稍微重新排列代码来避免此问题并提高清晰度。例如，而不是：

if (!cond) {
    do_this();
}
else {
    do_that();
}

您可能会写：

if (cond) {
     do_that();
}
else {
    do_this();
}

这并不总是更好，但是在适当的地方寻找机会也没有什么坏处。

摘要：在C和C ++，平等比较，true并且false是危险的，过于冗长，差的风格。在许多其他语言中，这样的比较可能并不危险，但它们仍然过于冗长且风格欠佳。

如果condition == false确实对您来说“英语更加自然”，那么我必须假定您不是母语人士。否则我无法解释这一点，因为没人会这样说：

如果阳光明媚，那我就呆在家里。

比较一下

如果没有阳光，我待在家里。

就是说，我同意!在代码中很容易忽略单个细长的字符。因此，not当语言支持时，我更喜欢使用关键字。例如C ++ 确实允许这样做，尽管许多程序员对此并不了解。

对于需要的语言!，我在运算符和操作数之间放置一个空格。这使否定变得更加难以忽略：

if (! condition) { … }

请注意，每个程序员都应自动将其翻译为“无条件”，而无需三思。在阅读代码习惯时获得这种流利程度是成为一名优秀程序员的第一步。

两者在功能上是相同的，因此使用哪一个取决于口味。

我使用的主要原因== false是，我发现!在查看代码时太容易忽略了。

被这个问题严重咬伤后，我养成了在测试错误时非常清楚的习惯。

如果操作员not在Pascal中被命名为，我认为这不会成为问题。

当我看到时，var == false我总是想知道var是布尔值还是具有两个以上值的逻辑类型（例如，a maybe和an undefined以及trueand和false或类似IEEE 1164的九个值）。

因为有时您可能会写boolean = false（带有明显的错误）并且false == boolean看起来并不自然（无论练习有多好）

if (!boolean_variable)转换为if the condition is not true。

if (boolean == false)转换为if the condition not false is true。因为那是逆逻辑，所以很难理解。

在（很多）较旧的编译器中，我相信它们会将（布尔==假）分解为2个寄存器分配和一个机器语言比较代码。第一个示例将分为一个赋值和一个NOT运算符。就性能而言，与按位取反（1个时钟）相比，比较操作将花费多个时钟周期，具体取决于要比较的寄存器的大小，并且执行起来会较慢。

话虽这么说，我相信较新的编译器可以解决这个问题，因此可以选择两者之一。

在工作中，我经常处理可以为null的布尔值，因此我经常将这种情况编码为

if (value != null && value == true){
    //do something
}

因为我个人觉得对称使阅读更容易。特别是如果还有其他布尔值也在测试中。

我真的不在乎一种方式。

当测试真实条件时，只做一次就很有意义if (condition)，尤其是当您应用以'is'开头的布尔变量命名约定时：if (isOpen)完全清楚，使用!= false将是多余的。

对于C / C ++ / Java / etc。程序员的意思是“！” 操作符被完全吸收，以至于我们在看到它时会自动想到“ not”。所以拥有对我来说if (!isOpen)很清楚if (_NOT_ isOpen)。但是您还不够熟悉，在C / C ++中，您可以使用创建宏#define _NOT_ !。但是请相信我，几年后这完全没有必要。

除此之外，始终最好测试布尔值而不将它们与文字进行比较。例如，进行测试if (x == true)是很危险的，因为如果布尔值不为零，则布尔值被视为true，而文字true仅有一个特定值，因此x可能为“ true”（即非零），并且比较结果仍为false（因为它是包含2，而字面的true表示为1。）当然，这不适用于带有false的比较，但是如果在测试true时不使用它，为什么在测试false时使用它？

大小事项 ;）

在混合表达式中，更容易阅读：

boolean1 = false
boolean2 = true

p ! boolean1 and ! boolean2
p boolean1 == false and boolean2 == false

特别是在红宝石方面，有一个很大的区别：

boolean = nil
p ! boolean         #-> true
p boolean == false  #-> false

nil不是假的，但也不是真的。

根据我的经验以及您所链接的问题的答案。

有些人更喜欢使用if（condition），因为它写的时间较短。对我来说，这实际上是有道理的，例如（！isValidated（））我读为“未验证”。但对我而言，这全都是基于个人喜好，并且取决于isValidated（）方法的逻辑结构，无论它返回true还是false

如果您正确命名了变量，则!boolean更为自然。not boolean对于任何一个足以使程序员能够精读代码的人来说，它的读物都是如此。

对于某些人来说，越早表达意思就越好。

对于那些拥有“ if！...”的人来说，它们比“ if ...”要快得多，因此必须通读整个条件（实际上可能很长，例如（thisThing = thatThing或某物=另一件事）或（只是找到末尾的== false。

有！（我实际上更喜欢在语言允许的情况下使用not）在这种情况下，就可以提前获得英语的“ not”。

这个问题也导致考虑使用until支持它的语言，例如做“常见的事情”直到事情完成。正如其他人所说，自然语言表达是目标。我喜欢上面的“阳光明媚”示例。

另一个原因是，如果您在使用多种语言的代码库中工作，那么如果有一种惯用的方式来完成所有语言中的安全操作，那么在所有地方都采用这种方式是一个非常好的主意，以便您养成良好的习惯并且不太可能绊倒。

我想不出任何地方if (!variable)（或等价物如if not variable根据您的语言）是不是安全的，而如if self.is_ready() == False: ...没有安全的蟒蛇，如果self.is_ready()回报率None，现在还是将来，这将是一个完全合理的事情为它做表示还没有准备好，因为None和一样虚假False。