在我工作的公司，最近有一项要求，即所有“高度可见”的布尔逻辑必须以析取范式表示。
因此（例如，虽然这个概念与语言无关），
#if (defined(A) || defined( B )) || (defined(C) && defined(D))
必须替换为：
#if defined(A) || (defined(C) && defined(D)) || defined(B)
强制要求代码必须以这种方式表达的动机是什么？有什么好处？
答案 0 :(得分：4)
优点是在代码库中的任何地方以规范/规范化形式表达这样的逻辑（理论上）将使程序员更容易理解和维护它。
如果没有这样的规则，一些程序员就会尝试以这样的方式“优化”表达式，使维护者很难解开它。此外，如果有必要，可以使用常用表单来组合新表达式。
（这些优势是值得商榷的。与任何风格指南一样，遵循一致的规则比选择一条规则更重要。）
答案 1 :(得分：1)
虽然您的示例很差（两个表达式都在DNF中），但我可以看到为什么有人会强制执行此政策。
任何普通形式的优点是所有表达式现在都具有相同的形式。在DNF中，该表格是条款/条件的列表，其中一个必须是真实的。这些条款反过来是文字/条件的列表，每个都必须是真实的。
DNF特别具有以下优势：在大多数语法中，和的优先级高于或，而不具有更高的优先级，因此DNF比CNF需要更少的括号，省略括号不是错误。
答案 2 :(得分：1)
很多时候，您所拥有的编码标准并不像始终如一地执行它们那么重要。持续编写代码大大提高了可读性，很多时候决定选择哪些人的人正在行使个人喜好而不是编码智慧。
假设您列出的标准确实有帮助。我会说，大多数人都没有意识到＆amp;＆amp; amp;运算符具有比||更高的运算符优先级所以在＆amp;＆amp;和运算符和操作数有助于使事情更加明确。
永远记住，在许多语言中，如果只能在评估其中一个操作数后确定表达式的值，则可能无法执行布尔表达式的操作数。如：
1：（trueMethod（）|| falseMethod（））
2：（falseMethod（）|| trueMethod（））
如果只执行一个trueMethod（）。但是在案例2中，两种方法都被执行了。订单可以带来很大的不同。