显式比较布尔常量是不好的，例如，Java中的if（b == false）？
写这个不好吗？
if (b == false) //... while (b != true) //... 反而总是写得更好：
if (!b) //... while (!b) //...
（大概是这样吗？），但是你怎么衡量两者之间的明确性，简洁性，清晰性和可读性等？
更新
为了限制主观性，我还要感谢来自权威编码风格指南的任何引用，这些引用总是比较好用的，或者在何时使用。
注意 ：variables名称b仅用作示例，ala foo和bar 。
这不一定是坏事，只是多余的。 而且，实际的variables名称也是很重要的。 例如， if (userIsAllowedToLogin) if (b) if (userIsAllowedToLogin) ， if (userIsAllowedToLogin) 。
至于性能问题，编译器会以任何方式优化它。
更新 ：对于权威来源，我无法在Sun编码约定中明确地find某些东西，但至lessCheckstyle有一个SimplifyBooleanExpression模块，它会提醒您。
你不应该使用第一种风格。 我见过有人使用：
-
if ( b == true ) -
if ( b == false )
我个人觉得很难阅读，但它是可以通过的。 然而，我遇到的一个很大的问题就是，它会导致你展现的令人难以置信的反直觉的例子：
-
if ( b != true ) -
if ( b != false )
读者需要花费更多的精力来确定作者的意图。 就我个人而言，我发现包括一个明确的比较是真实的还是错误的，是多余的，因此难以阅读，但这就是我。
这是一个强烈的品味问题。
就我个人而言，我发现if (!a) {比if (a == false) {更不可读 （编辑：对我来说if (a == false) {因此在稍后维护代码时更容易出错，并且已经转换为使用后者的forms。
基本上我不喜欢select逻辑运算的符号而不是单词（C对Pascal），因为对于我来说 a = 10 and not b = 20比a == 10 && !(b==20)更容易读取，但是这是它在Java中的方式。
任何把“==虚假”方法放在“！ 显然从来没有盯着代码太久，错过了感叹号。 是的，你可以得到代码盲目。
为什么你不应该使用第一种风格的首要原因是因为这两个都是有效的：
if (b = false) //... while (b = true) //...
也就是说，如果不小心遗漏了一个字符，就会创build一个赋值而不是比较。 一个赋值expression式的计算结果是赋值的，所以上面的第一个语句将赋值为b的值赋值为false 。 第二个赋值给b ，因此无论你在循环中用b做什么，它总是计算为true 。
除了初学者编写的代码之外，我从未见过前者; 它总是后者，我不认为有人会为此感到困惑。 另一方面，我想
int x; ... if(x) //...
VS
if(x != 0) //...
是更有争议的，在这种情况下，我更喜欢第二个
恕我直言，我想如果你只是使用"Is"前缀的布尔variables名，这将是自我明显，更有意义的，然后，你可以删除显式比较true或false
例：
isEdited // use IsEdited in case of property names isAuthorized // use IsAuthorized in case of property names
等等
我更喜欢第一个，因为它更清晰。 机器可以同时读取，但我试图编写代码供其他人阅读，而不仅仅是机器。
我更喜欢长期的方法，但我比较使用==而不是!= 99％的时间。
我知道这个问题是关于Java的，但我经常在语言之间切换，例如，在C# ，与（forntance） == false可以帮助处理可空的布尔types。 所以我得到这个比较true或false但使用==运算符的习惯。
我做这些：
if(isSomething == false)或者if(isSomething == true)
但我讨厌这些：
if(isSomething != false)或者if(isSomething != true)
由于明显的可读性原因！
只要你保持你的代码可读性，那就没有关系了。
在我看来，这只是烦人的。 不是我会引起骚动的。
就个人而言，我会重构代码，所以我没有使用负面testing。 例如。
if (b == false) { // false } else { // true }
要么
boolean b = false; while(b == false) { if (condition) b = true; }
恕我直言，在90％的情况下，代码可以重构，所以不需要负面的testing。
正常的指导方针是从不testing布尔值。 有些人认为，增加了更多的清晰度。 添加的代码可能会帮助一些人，但是每个读者都需要阅读更多的代码。
今天早上，我已经失去了半小时find一个错误。 代码是
if ( !strcmp(runway_in_use,"CLOSED") == IPAS_FALSE) printf(" ACTIVE FALSE \n"); else printf(" ACTIVE TRUE \n");
如果是按照惯例编码的话，我会更快地看到它是错误的：
if (strcmp(runway_in_use, "CLOSED")) printf(" ACTIVE FALSE \n"); else printf(" ACTIVE TRUE \n");
我会说这是不好的。
while (!b) { // do something }
读得比
while (b != true) { // do something }
第一个原因（b ==假）的原因之一就是，初学者经常没有意识到第二种select（！b）是完全可能的。 所以使用第一种forms可能会导致布尔expression式和布尔variables的误解。 这样，使用第二种forms已经成为了某种程度上的事情：当有人写这个时，他/她可能会理解正在发生的事情。
我相信这导致差异被认为比实际更重要。
