用Java编写布尔表达式的首选方法是什么答案

【问题标题】：What is the preferred way to write boolean expressions in Java用Java编写布尔表达式的首选方法是什么
【发布时间】：2010-03-09 13:43:07
【问题描述】：

我总是这样写我的布尔表达式：

if (!isValid) {
  // code
}

但我的新雇主坚持以下风格：

if (false == isValid) {
  // code
}

一种风格是首选还是标准？

【问题讨论】：

哇，还有一个要问潜在雇主的问题。（明确地与布尔常量进行比较是愚蠢的。）
我会说第二个是首选.......当且仅当你是一个代码混淆器
虽然我更喜欢第一个，但您可能想坚持雇主的标准
感谢您的反馈。我们会看看我是否能改变团队中的标准。
另见stackoverflow.com/questions/2661110/…

标签： java coding-style boolean

【解决方案1】：

我更喜欢第一种风格，因为它对我来说阅读起来更自然。看到第二种风格很不寻常。

有些人可能更喜欢第二种而不是另一种选择的原因之一：

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

是后者你不小心写了一个= 而不是== 然后你分配给isValid 而不是测试它，但是首先使用常量你会得到一个编译错误。

但是根据您的第一个建议，这个问题甚至不是问题，所以这是首选第一个的另一个原因。

【讨论】：

实际上，如果 isValid 是一个变量（除非 isValid 是 final），则该错误不会出现编译错误。这真的，真的很糟糕。显然，如果 isValid 是一个方法或一个表达式，问题不大，但作为一种习惯......
我相信这就是订单反转的原因。 “if (false=isValid)”是一个错误。

【解决方案2】：

绝对是第一。第二个暴露了对表达式和值的本质缺乏理解，并且作为编码标准的一部分，它意味着雇主希望雇用非常不称职的程序员 - 这不是一个好兆头。

【讨论】：

你杀了我。但至少这意味着我没有疯。

【解决方案3】：

每个人都认识这个 sn-p：

if (isValid.toString().lenght() > 4) {
   //code
}

我认为你的第二个例子是同一个方向。

【讨论】：

【解决方案4】：

几个小时前 C# 是 discussed。

false == isValid 构造是 C 世界的遗留物，编译器允许您在 if 语句中进行赋值。我相信 Java 编译器会在这种情况下警告你。

总的来说，第二个选项太冗长了。

【讨论】：

表达式中的布尔赋值不会在 Eclipse 中向我显示任何编译器错误或警告。
一般布尔赋值不会，但尝试为内置常量'false'分配值会 - 因此排序。在旧的 C 代码（我的意思是 OLD）中，FALSE 通常是一个赋值变量，可以被覆盖。

【解决方案5】：

IMO 第一个更易读，而第二个更冗长。

我肯定会选择第一个

【讨论】：

【解决方案6】：

您正在评估变量，而不是 false，因此从可读性的角度来看，后者是不正确的。所以我个人会坚持第一个选项。

【讨论】：

【解决方案7】：

我将在这里尝试一个综合性的答案，其中包含上述所有答案。

第一种风格肯定是首选，原因如下：

它更短
它更具可读性，因此更容易理解
使用更广泛，这意味着读者将更快地识别模式
“false==...”而不是“...==false”是又一次违反自然秩序，让读者觉得“有什么奇怪的事情需要注意吗”，没有的时候。

唯一的例外是当变量是布尔值而不是布尔值时。在这种情况下，第二个表达式与第一个表达式不同，当 isValid 为 null 以及 Boolean.FALSE 时，计算结果为 false。如果是这种情况，使用第二个有很好的论据。

【讨论】：

【解决方案8】：

第二种样式不需要您自己否定表达式（这可能比“isValid”复杂得多）。但是如果你忘记输入两个 =，写“isValid == false”可能会导致意外的赋值，因此习惯用法是把不能是右值的东西放在右边。

第一种风格似乎更受那些知道自己在做什么的人的欢迎。

【讨论】：

【解决方案9】：

我只想说我 20 年前在学校学习了 C，然后转向 Perl 和 Java，现在又转向 C#，它们都具有相同的语法和......

我认为 (!myvar) 是最受欢迎的

我认为 (myvar==false) 也很好

20 年来我从未见过

(false==myvar)

我认为你的老板在抽烟——我很抱歉，但我认为这表明你的老板是某种控制狂或麻木。

【讨论】：