Question

好的，我们知道以下两行是等价的 -

(0 == i)
(i == 0)

此外，过去鼓励使用第一种方法，因为如果您不小心使用'='而非'=='，编译器会发出错误消息。

我的问题是 - 在今天一代漂亮的IDE和智能编译器中，你还推荐第一种方法吗？

特别是，当我看到以下代码时，这个问题突然出现在我的脑海中 -

if(DialogResult.OK == MessageBox.Show("Message")) ...

在我看来，我绝不会推荐上述内容。任何第二意见？

Answer 1

我更喜欢第二个，（i == 0），因为阅读时感觉更自然。你问人们，“你是21岁还是以上？”，不是，“21岁是否小于或等于你的年龄？”

Answer 2

如果你把变量放在第一个或最后一个，那么在C＃中无关紧要，因为赋值不会计算为bool（或可转换为bool的东西），因此编译器会捕获任何错误，如“if（i = 0）EntireCompanyData .Delete（）“

所以，至少在C＃世界，它是一种风格而不是绝望。对于说英语的人而言，将变量放在最后是不自然的。因此，对于更易读的代码，首先变量。

Answer 3

如果你有一个无法用开关代表的ifs列表（可能是因为语言限制），那么我宁愿看到：

if (InterstingValue1 == foo) { } else
if (InterstingValue2 == foo) { } else
if (InterstingValue3 == foo) { }

因为它可以让您快速查看需要检查的重要值。

特别是在Java中我发现它很有用：

if ("SomeValue".equals(someString)) {
}

因为someString可能为null，所以你永远不会得到NullPointerException。如果要比较对于可能为null的对象，您知道永远不会为null的常量，则同样适用。

Answer 4

（0 == i）

我会一直选这个。确实，今天的大多数编译器都不允许在条件语句中赋值变量，但事实是有些人会这样做。在今天的网络编程中，我必须在系统上使用无数语言。通过使用0 == i，我总是知道条件语句是正确的，我不依赖编译器/解释器来解决我的错误。现在，如果我必须从C＃跳转到C ++或JavaScript，我知道我不必在代码中跟踪条件语句中的赋值错误。对于这么小的东西，并节省了这么多时间，这是一个没有脑子。

Answer 5

我曾经确信更易读的选项（i == 0）是更好的选择。

然后我们有一个生产错误（不幸的是），其中问题是（$ var = SOME_CONSTANT）类型错误。客户开始收到适用于其他客户的电子邮件。敏感类型数据。

你可以说Q / A本应该抓住它，但他们没有，这是一个不同的故事。

从那天起，我总是推动（0 == i）版本。它基本上消除了这个问题。感觉不自然，所以你要注意，所以你不要犯错误。这里根本没办法搞错。

在代码审查中有人没有反转if语句比在有人意外地在if中分配值更容易。如果格式是编码标准的一部分，那么人们就会寻找它。人们通常不会在代码审查期间调试代码，并且眼睛似乎扫描a（i = 0）vs（i == 0）。

我也是java“常量字符串”.equals（dynamicString）的忠实粉丝，没有空指针异常是一件好事。

Answer 6

你知道，我总是使用条件的 if（i == 0）格式，我这样做的原因是我用C＃编写了大部分代码（这会标记其他代码）反正一个）我对我的开发做了一个测试优先的方法，我的测试无论如何都会抓住这个错误。

我曾在商店里工作过，他们试图强制执行0 == i格式，但我觉得写作很尴尬，难以记住，它最终成为寻找低调水果的代码审稿人的饲料

Answer 7

实际上，DialogResult示例是我推荐该样式的地方。如果可以看到它将if（）的重要部分放在左侧。如果它在右边并且MessageBox有更多参数（很可能），你可能需要向右滚动才能看到它。

OTOH，我从未在“（0 == i）”风格中看到太多用处。如果你能记得把常数放在第一位，你可以记得使用两个等号，

Answer 8

我总是尝试使用第一种情况（0 == i），这样可以挽救我的生命几次！

Answer 9

我更喜欢（i == 0），但我仍然为自己制定一个“规则”（0 == i），然后每次都打破它。

“嗯？”，你想。

好吧，如果我做出了一个在左边放一个左值的有意识的决定，那么如果我输入“=”代表“==”，那么我会对我输入的内容给予足够的关注。我希望。在C / C ++中，我通常使用-Wall作为我自己的代码，无论如何，它会在gcc上为大多数“=”生成“==”错误警告。我不记得最近看到这个警告，也许是因为我编程的时间越长，我就越是反思性地偏执，我之前犯过的错误......

if(DialogResult.OK == MessageBox.Show("Message"))

似乎误入歧途。诀窍的重点是避免意外分配某些东西。

但是谁会说DialogResult.OK是否比MessageBox.Show（“Message”）更多或更不可能评估为可分配类型？在Java中，方法调用不可能是可分配的，而字段可能不是最终的。因此，如果你担心输入= for ==，那么在这个例子中它实际上应该是Java的另一种方式。在C ++中，两者都不可分配。

（0 == i）只是有用，因为你绝对肯定知道数字文字永远不可分配，而我可能就是。

如果您的比较的两边都是可分配的，那么您就无法通过这种方式保护自己免于意外分配，并且当您不知道哪个是可分配的而不进行查找时，就会发生这种情况。没有什么神奇的技巧可以说“如果你把它们放在反直觉的方式，你就会安全”。虽然我认为它引起了对这个问题的关注，就像我的“总是违反规则”规则一样。

Answer 10

我认为这只是风格问题。它确实有助于意外使用赋值运算符。

我绝对不会要求程序员长大。

Answer 11

我使用（i == 0）的原因很简单，因为它读得更好。它在我的头脑中流动非常顺畅。当您将代码读回自己进行调试或其他目的时，它只是像读书一样流动而且更有意义。

Answer 12

我公司刚刚从编码标准中删除了if（0 == i）的要求。我可以看到它有多大意义，但在实践中它似乎倒退了。有点遗憾，默认情况下，C编译器可能不会给出关于if（i = 0）的警告。

Answer 13

第三个选项 - 完全禁止在条件内部分配：

在高可靠性情况下，您不允许（在前面的注释中没有很好的解释）在条件语句中分配变量 - 它完全消除了这个问题，因为您要么在编译器中关闭它，要么使用LINT关闭它非常受控的情况你可以使用它。

请记住，无论分配是在条件内还是外部发生，通常会生成相同的代码 - 它只是减少代码行数的捷径。该规则总是存在例外情况，但它永远不会处于条件状态 - 如果需要，您可以随时写出来。

因此，另一种选择仅仅是禁止此类语句，并在需要时使用注释关闭LINT检查此常见错误。

- 亚当

Answer 14

就我个人而言，我不喜欢（1）并且总是做（2），但是在处理对话框和其他可能超长的方法时，为了可读性而反转。它看起来并不坏，但是如果你将MessageBox扩展到它的全长。你必须一直向右滚动以找出你要返回的结果。

因此，虽然我同意您对值类型的简单比较的断言，但我不一定认为它应该是消息框之类的规则。

Answer 15

两者都是相同的，但我更喜欢0 == i变体。

比较字符串时，比较“MyString”.equals（getDynamicString（））

更容易出错

因为，getDynamicString（）可能返回null。写得更有意义，写0 == i

Answer 16

嗯，这取决于所讨论的语言和编译器。语境就是一切。

在Java和C＃中，除了非常罕见的比较两个布尔值的情况之外，“赋值而不是比较”拼写错误最终会导致无效代码。

我可以理解为什么人们可能想在C / C ++中使用“安全”形式 - 但坦率地说，大多数C / C ++编译器会警告你，无论如何你都会输入错字。如果您使用的编译器没有，您应该问问自己为什么：）

第二种形式（变量然后是常数）在我的视图中更具可读性 - 所以无论何时它都不会导致问题，我都会使用它。

Answer 17

对于大于几百行的代码，代码可读性是最重要的事情之一，绝对i == 0读取比反向更容易

Answer 18

在C中，是的，但您应该已经打开了所有警告并且正在编译无警告，并且许多C编译器将帮助您避免此问题。

我很少从可读性POV中看到很多好处。

Answer 19

我会说（i == 0）听起来更自然，如果你试图用简单（和模棱两可的）英语短语。这实际上取决于程序员的编码风格或者他们需要遵守的标准。

Answer 20

所有编码标准的规则0都应该是“编写可以被其他人轻松阅读的代码”。出于这个原因，我选择（最快速变化的值）测试（不太快速变化的值，或常数），即在这种情况下“i == 0”。

即使这种技术很有用，规则应该是“避免在比较的左边放一个左值”，而不是“总是在左边放任何常数”，这通常是解释它的方式 - 例如，写作没有任何好处

if (DateClass.SATURDAY == dateObject.getDayOfWeek())

如果getDayOfWeek（）返回一个常量（因此不是左值）！

我很幸运（在这方面，至少）在这些日子里，我主要使用Java进行编码，如上所述，if（someInt = 0）将无法编译。

关于比较两个布尔值的警告有点像红鲱鱼，因为大多数时候你要么比较两个布尔变量（在这种情况下交换它们没有帮助）或者测试是否设置了一个标志如果我发现你在条件中明确地与 true 或 false 进行比较，那么你会感到懊悔！ GRRRR！

Answer 21

我认为唯一强迫一方胜过另一方的因素是工具链是否提供警告来捕捉表达式中的赋值。我作为开发人员的偏好是无关紧要的。通过清楚地呈现业务逻辑可以更好地服务于表达。如果（0 == i）比（i == 0）更合适，我会选择它。如果不是，我会选择另一个。

表达式中的许多常量由符号名称表示。某些样式指南还限制了可用于标识符的词性。我使用这些作为指导来帮助塑造表达式的读取方式。如果结果表达式松散地读取伪代码，那么我通常会满意。我只是让表达表达自己，如果我错了，它通常会陷入同行评审中。

Answer 22

你是正确的，首先放置重要组件有助于提高可读性，因为读者倾向于主要浏览左栏，并在那里放置重要信息有助于确保它被注意到。

然而，永远不要与同事交谈，并暗示即使在开玩笑中你的行动也不会在这里得到高分。

Answer 23

这是我最大的宠儿之一。没有理由降低代码可读性（如果（0 == i），什么？0的值怎么改变？）来捕捉过去二十年中编写的任何C编译器都能自动捕获的内容。

是的，我知道，大多数C和C ++编译器默认情况下不启用此功能。查找正确的开关以将其打开。没有理由不知道你的工具。

当我看到它爬进其他语言（C＃，Python）时，它真的会让我感到紧张，这通常会标记它！

Answer 24

也许不是你问题的答案。我尝试使用===（检查相同）而不是相等。这样就不会进行类型转换，它会强制程序员确保传递正确的类型，

Answer 25

我个人更喜欢使用变量操作数值格式，部分原因是因为我一直在使用它，感觉“自然”，部分原因是因为它似乎是主流惯例。有些语言使用赋值语句，如下所示：

:1 -> x

因此，在这些语言的上下文中，即使它是有效的，看到以下内容也会变得非常混乱：

:if(1=x)

所以这也是需要考虑的事情。我同意消息框响应是一种情况，其中使用值 - 操作数 - 变量格式从可读性角度来看效果更好，但如果您正在寻找稳定性，那么您应该放弃它的使用。

Answer 26

我总是选择第二种方法。在C＃中，写

if (i = 0) {
}

无论如何，

导致编译器错误（无法将int转换为bool），因此您可能犯错误实际上不是问题。如果你测试bool，编译器仍然会发出警告，你不应该将bool与true或false进行比较。现在你知道了为什么。

Answer 27

我们可能会继续谈论我们的IDE有多好，但我仍然对那些将IDE的警告级别降低的人感到震惊。

因此，对我而言，最好让人们使用（0 == i），因为你永远不知道，哪个程序员正在做什么。最好是“安全而不是抱歉”

Answer 28

if(DialogResult.OK == MessageBox.Show("Message")) ...

我总是建议以这种方式写比较。如果MessageBox.Show（“Message”）的结果可能为null，那么如果比较是相反的，那么你冒着NPE / NRE的风险。

在包含NULL的世界中，数学和逻辑运算不是自反的。

如何检查等于？（0 == i）或（i == 0）

28 个答案:

第三个选项 - 完全禁止在条件内部分配：

如何检查等于？ （0 == i）或（i == 0）

28 个答案:

第三个选项 - 完全禁止在条件内部分配：

如何检查等于？（0 == i）或（i == 0）