私が働いている会社では、最近、すべての「非常に可視性の高い」ブール論理を選言標準形で表現する必要があるという義務があります。
したがって、たとえば（概念は言語に依存しませんが）、
#if (defined(A) || defined( B )) || (defined(C) && defined(D))
次のように置き換える必要がありました：
#if defined(A) || (defined(C) && defined(D)) || defined(B)
コードをこのように表現する必要があることを義務付ける動機は何ですか？利点は何ですか？
利点は、コードベース内のあらゆる場所でそのようなロジックを標準化/正規化された形式で表現すると、(理論的には) プログラマーがそれを理解し維持しやすくなるということです。
そのような規則がなければ、一部のプログラマーは、メンテナーがそれを解明するのが難しくなるような方法で式を「最適化」しようとする傾向があります。また、共通のフォームを使用すると、必要に応じて新しい式を簡単に作成できます。
(これらの利点については議論の余地があります。他の文体のガイドラインと同様に、従うべき一貫した規則を持つことは、代替案よりも 1 つの規則を選択するよりも重要です。)
多くの場合、使用しているコーディング標準は、それらを一貫して実装するほど重要ではありません。一貫してコードを記述しておくと、読みやすさが大幅に向上し、多くの場合、どちらを選択するかを決定する人々は、コーディングの知恵ではなく、個人的な好みを行使しています。
あなたがリストした基準が実際に役立つと仮定します。ほとんどの人は、&&演算子の方が||よりも演算子の優先度が高いことに気づいていません。したがって、&&演算子とオペランドの前後に（）を使用すると、物事をより明確にするのに役立ちます。
多くの言語では、一方のオペランドだけを評価した後で式の値を決定できる場合、ブール式の両方のオペランドが実行されない可能性があることを常に覚えておいてください。そのような：
1：（trueMethod（）|| falseMethod（））
2：（falseMethod（）|| trueMethod（））
1つの場合はtrueMethod（）のみが実行されます。ただし、ケース2では、両方のメソッドが実行されます。注文は大きな違いを生む可能性があります。
あなたの例は非常に貧弱ですが (どちらの式も DNF にあります)、誰かがこのポリシーを課す理由はわかります。
通常の形式には、すべての式が同じ形式になるという利点があります。DNF では、そのフォームは句/条件のリストであり、そのうちの 1 つが真でなければなりません。節は、リテラル/条件のリストであり、それぞれが真でなければなりません。
DNF には特に、ほとんどの構文でorよりも優先順位が高く、優先順位が高くないという利点があるため、DNF は CNF よりも必要な括弧が少なく、括弧を省略してもエラーにはなりません。