即使在没有必要的情况下，我也应该在逻辑语句中使用括号吗？

假设我有一个布尔条件，a AND b OR c AND d并且我使用的语言中AND的操作先例比的先后顺序高OR。我可以编写以下代码行：

If (a AND b) OR (c AND d) Then ...

但实际上，这等效于：

If a AND b OR c AND d Then ...

是否有支持或反对包含多余括号的论点？实践经验是否表明值得将它们包括在内以提高可读性？还是表明开发人员需要真正坐下来并对他们的语言基础充满信心？

优秀的开发人员努力编写的代码是明确的和正确的。即使没有严格要求，带条件的括号也可以帮助您。

为了清楚起见，请考虑一下括号，例如代码中的注释：它们并不是严格必须的，并且从理论上讲，有能力的开发人员应该能够在没有它们的情况下找出代码。但是，这些提示非常有用，因为：

• 它们减少了理解代码所需的工作。
• 他们提供了开发者意图的确认。

此外，额外的括号（如缩进，空格和其他样式标准）有助于以逻辑方式直观地组织代码。

至于正确性，没有括号的条件是愚蠢错误的诱因。当它们发生时，它们可能是很难发现的错误-因为通常情况下，错误的条件在大多数情况下都会正确执行，并且偶尔会失败。

即使您做对了，下一个处理您的代码的人也可能不会这样做，要么在表达式中添加错误，要么误解您的逻辑，从而在其他地方添加错误（正如LarsH正确指出的那样）。

我总是用括号相结合的表现形式and和or（也用于算术运算类似的优先问题）。

它的事项是否少你在你的语言的把握有信心。更重要的是紧随您之后的n00b语言的掌握。

以最清晰，最明确的方式编写代码。多余的括号通常（但不总是）有帮助。在一行上仅放置一个语句通常会有所帮助。编码风格的一致性通常会有所帮助。

括号太多了，但这是您不需要建议的情况之一-当您看到它时便会知道。到那时，重构您的代码以减少语句的复杂性，而不是删除括号。

是

您应该始终使用括号...您无法控制优先级顺序...编译器的开发人员可以。这是我发生的一个不使用括号的故事。这在两周内影响了数百人。

现实世界中的原因

我继承了一个大型机应用程序。有一天，它突然失去作用了。就这样... po声就停了下来。

我的工作是使它尽快运行。源代码已经有两年没有被修改，但是突然间它就停止了。我试图编译代码，但它在XX行上中断了。我看着XX行，但我不知道是什么使XX行中断。我询问了此应用程序的详细规格，但没有。XX行不是罪魁祸首。

我打印出了代码，并开始从上至下进行审查。我开始创建正在发生的事情的流程图。代码太复杂了，我什至无法理解。我放弃尝试绘制流程图。我很害怕做出更改，却不知道该更改将如何影响其余的过程，尤其是因为我没有应用程序的功能或依赖链中的位置的详细信息。

因此，我决定从源代码的顶部开始，并添加whitespce和行制动器，以使代码更具可读性。我注意到，在某些情况下，如果条件组合在一起AND，OR并且在AND编辑什么数据和编辑什么数据之间并没有明显的区别OR。因此，我开始在AND和OR条件周围加上括号，以使其更具可读性。

当我慢慢进行清理时，我会定期保存工作。有一次我尝试编译代码，然后发生了一件奇怪的事情。该错误已跳过原始代码行，而现在进一步降低了。所以我继续，用括号分隔了AND和OR条件。当我完成清理工作时。去搞清楚。

然后，我决定访问操作车间，询问他们最近是否在主机上安装了任何新组件。他们说是的，我们最近升级了编译器。嗯

事实证明，旧的编译器无论如何都从左到右评估表达式。新版本的编译器还从左到右评估表达式，但是代码含糊不清，这意味着不清楚的组合AND并且OR无法解决。

我从中学到的教训...总是，总是，总是使用括号将AND条件和OR条件相互结合使用。

简化示例

IF Product = 191 OR Product = 193 AND Model = "ABC" OR Product = 201 OR Product = 202 AND Model = "DEF" ...（其中的代码杂乱无章）

这是我遇到的问题的简化版本。复合布尔逻辑语句还有其他条件。

我记得将它赶到：
IF ((Product = 191 OR Product = 193) AND Model = "ABC") OR ((Product = 201 OR Product = 202) AND Model = "DEF") ...

我无法重写它，因为没有规范。原始作者早已不复存在。我记得压力很大。一整艘货船被困在港口，无法卸载，因为这个小程序不起作用。没有警告。无需更改源代码。在我发现添加括号改变了错误之后，我才问网络运营商是否修改了任何内容。

是的，如果混合使用“和”和“或”。

（）逻辑上是一种检查也是个好主意。

尽管最好的方法是使用命名谓词函数，并在其中逐出大多数检查和条件，如果简单易懂，就保留它们。

括号在语义上是多余的，因此编译器不在乎，但这是一个红色的鲱鱼-真正的问题是程序员的可读性和理解力。

我将在这里采取激进立场，并对中的括号表示诚挚的“不” a AND b OR c AND d。每个程序员都应该从心底知道布尔表达式的优先级不是NOT> AND> OR，就像记住“ 请为我亲爱的萨莉姨妈打扰 ”代数表达式一样。多余的标点符号大多数时候只会在代码中增加视觉混乱，而对程序员的可读性没有好处。

另外，如果您总是在逻辑和代数表达式中使用括号，那么您就放弃了使用它们作为标记的能力，因为“这里发生了一些棘手的事情-注意！” 也就是说，在您要覆盖默认优先级并在乘法运算之前或在与运算符AND之间进行加法运算的情况下，括号对下一个程序员来说是一个不错的警告。当不需要它们时，过多地使用它们，您就会成为哭狼的男孩。

对于代数领域之外的任何事物（不管是否为布尔值），例如C语言中的指针表达式，我都会作例外处理，其中比标准习语更复杂的事物（例如*p++或p = p->next可能应加括号），以保持解引用和算术的直接性。而且，当然，这都不适用于使用某种形式的波兰语表示法的Lisp，Forth或Smalltalk等语言。但是对于大多数主流语言，逻辑和算术优先级是完全标准化的。

照我看来：

是的优点：

• 操作顺序是明确的。
• 保护您免受那些不了解操作顺序的未来开发人员的侵害。

是缺点：

• 可能导致混乱，难以阅读的代码

没有优点：

• ？

没有缺点：

• 操作顺序是隐式的
• 对于开发人员，如果不充分了解操作顺序，则代码的维护性较差。

是否有支持或反对包含多余括号的论点？实践经验是否表明值得将它们包括在内以提高可读性？还是表明开发人员需要真正坐下来并对他们的语言基础充满信心？

如果没有其他人不得不再次查看我的代码，我认为我不在乎。

但是，根据我的经验：

• 我偶尔会再次查看我的代码（有时在写代码后的几年）
• 其他人有时看我的代码
  • 甚至必须扩展/修复它！
• 我自己或其他人都不会完全记得我在写时的想法
• 编写神秘的“减少字符数”代码会损害可读性

我几乎总是这样做，因为我相信我有能力快速阅读并且不会因小错误而犯更多的错误。

在您的情况下，我几乎可以肯定地说：

if (a AND b) then ab = true
if (c AND d) then cd = true
If (ab OR cd) Then ...

是的，这是更多代码。是的，我可以改做花式布尔运算符。不，我不希望将来再漏读1年以上的代码时会误读一些花哨的bool运算符。如果我用具有不同AND / OR优先级的语言编写代码并且不得不跳回以解决此问题怎么办？我要去吗，“啊哈！我还记得我所做的这个聪明的小事！去年写这篇文章时，我不必包括parens，现在我还记得好事！” 如果发生这种情况（或更糟的是，其他人没有意识到这种聪明之处，或者陷入了“尽快修复”类型的情况）？

用（）分隔使得快速浏览和稍后了解变得更加直接...

一般情况

在C＃中，乘法和除法优先于加法和减法。

尽管如此，StyleCop是一种在整个代码库中强制实施通用样式的工具，其附加目标是减轻可能不够清晰的代码引入的错误的风险，该工具具有规则SA1407。该规则将产生一条带有如下代码的警告：

var a = 1 + 2 * 3;

显然结果7不是9，但StyleCop仍建议加上括号：

var a = 1 + (2 * 3);

您的情况

在您的特定情况下，在您使用的特定语言中，AND优先于OR。

这不是每种语言的行为方式。许多其他人同样对待AND和OR。

作为主要使用C＃的开发人员，当我第一次看到您的问题并在不阅读您之前编写的内容的情况下阅读代码时，我的第一个诱惑就是评论这两个表达式不相同。希望我在评论之前已经阅读了整个问题。

这种特殊性以及某些开发人员可能认为AND和OR具有相同优先级的风险使得添加括号变得更加重要。

不要以表明自己很聪明为目标而编写代码。编写代码以提高可读性为目标，包括可能不熟悉该语言各个方面的人员。

众所周知，每次使用括号都会使表达式更具可读性。但是，如果表达式很复杂，建议您为子表达式引入新功能。

还是表明开发人员需要真正坐下来并对他们的语言基础充满信心？

如果您严格使用单数形式的语言，也许吧。现在将您所知道的所有语言，从古老到最现代，从编译到脚本编写再到SQL，再到您上个月发明的自己的DSL。

您还记得这些语言中每种语言的确切优先规则吗？

“即使在不必要的情况下，我也应该在逻辑语句中使用括号。”

是的，因为两个人会发现他们有帮助：

• 下一位程序员的知识，能力或风格可能会有所不同

• 将来您以后再返回此代码的将来！

复杂的条件条件是“布尔代数”，您可以通过某种方式编写它们，使其看起来非常像代数，而您肯定会使用parens作为代数，对吗？

真正有用的规则是取反规则：

!(A || B) <=> !A && !B
!(A && B) <=> !A || !B

或者，以更清晰的格式：

!(A + B) <=> !A * !B
!(A * B) <=> !A + !B

这是真的显然只是代数时所写：

-1*(A + B) = -A + -B
-1*(A * B) = -A * -B

但是我们也可以将思想用于代数的简化和扩展：

(A && B) || (C && D) => 
((A && B) || C) && ((A && B) || D) => 
(AC && BC) && (AD && BD) =>
AC && BC && AD && BD

尽管在代码中您必须编写：

(A||C) && (B||C) && (A||D) && (B||D)

或者，以更清晰的格式：

(A + B) * (C + D) => 
((A + B) * C) + ((A + B) * D) => 
(AC + BC) + (AD + BD) =>
AC + BC + AD + BD

基本上，条件表达式仍然只是代数表达式，通过清楚地使用括号，您可以更轻松地将已知的各种代数规则应用于表达式，包括“简化或扩展此公式”的古老概念。

即使括号是可选的，我也会使用括号，这是为什么，因为它有助于更​​好地为每个人，编写代码的人和准备看该代码的人理解。在您的情况下，即使布尔运算符也具有优先权，但一开始它可能会运行良好，但是我们不能说它会在每种情况下都对您有所帮助。所以我更喜欢在可能需要或可选的任何情况下使用用户括号。

是。在任何情况下，当您认为自己的代码会更清晰时，都应该使用。请记住，您的代码应该足够清晰，以便其他人可以理解而无需阅读代码内的注释。因此，使用括号和花括号是一个好习惯。还请记住，这可能取决于您的公司/团队的特定实践。只需保持一种方法，不要混淆。