必要でない場合でも、論理ステートメントで括弧を使用する必要がありますか？

ブール条件が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が正しく指摘しているように）。

andand を組み合わせた式or（および同様の優先順位の問題を伴う算術演算）には、常に括弧を使用します。

言語を理解していることに自信があるかどうかは重要ではありません。さらに重要なのは、後に続くn00bの言語を把握することです。

可能な限り明確で最も明確な方法でコードを記述してください。余分な括弧は、しばしば（常にではありませんが）役立ちます。多くの場合、1行に1つのステートメントのみを入力すると役立ちます。多くの場合、コーディングスタイルの一貫性が役立ちます。

括弧が多すぎるというようなこともありますが、アドバイスが必要ない状況の1つです。見ればわかるでしょう。その時点で、括弧を削除するのではなく、コードをリファクタリングしてステートメントの複雑さを軽減します。

はい

常に括弧を使用する必要があります...優先順位を制御しません...コンパイラの開発者が行います。括弧を使用しないことについて私に起こった話を次に示します。これは、2週間で何百人もの人々に影響を及ぼしました。

現実世界の理由

メインフレームアプリケーションを継承しました。ある日、澄んだ青から動き出しなくなりました。それだけです...パフは止まりました。

私の仕事は、できるだけ速く動作させることでした。ソースコードは2年間変更されていませんでしたが、突然停止しました。コードをコンパイルしようとすると、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") ...

仕様がなかったので書き直すことができませんでした。元の著者は長い間いなくなっていた。強いプレッシャーを覚えています。貨物船全体が港で立ち往生し、この小さなプログラムが機能しなかったため、荷を下すことができませんでした。警告なし。ソースコードに変更はありません。かっこを追加するとエラーがシフトすることに気付いた後、ネットワークオペレーションに何かを変更したかどうかを尋ねることになりました。

はい、「and」と「or」が混在している場合。

また、（）論理的に1つのチェックを行うことをお勧めします。

最良の方法は、適切な名前の述語関数を使用し、ほとんどのチェックと条件をそこに追い出し、単純で読みやすい場合はそのままにしておくことです。

括弧は意味的に冗長であるため、コンパイラーは気にしませんが、それは赤いニシンです-本当の懸念はプログラマーの可読性と理解です。

ここで急進的な立場を取り、の括弧に心のこもった「いいえ」を与えa AND b OR c AND dます。すべてのプログラマは、ブール式での優先順位が行くその心で知っておくべき、NOT> AND> ORばかり思い出すように、私の親愛なるおばさんサリーを許しなさい代数的表現のために。冗長な句読点は、ほとんどの場合コードに視覚的な混乱を追加しますが、プログラマの可読性には利点がありません。

また、論理式および代数式で常に括弧を使用する場合は、「ここでトリッキーなことが起こっている-気をつけてください！」のマーカーとしてそれらを使用する機能を放棄します。つまり、デフォルトの優先順位をオーバーライドし、乗算の前に、またはANDの前にORを追加で評価したい場合、括弧は次のプログラマーにとって良い赤い旗です。それらが必要でないときにそれらを使いすぎると、あなたはオオカミを叫んだ少年になります。

私は、標準的なイディオムのようなより複雑なものC、このようなポインタ式として、代数（ブール値かどうか）の領域外に何のための例外になるだろう*p++か、p = p->nextおそらくが逆参照を保持し、算術まっすぐにするために括弧されるべきです。そしてもちろん、これは、式にポーランド語表記の何らかの形式を使用するLisp、Forth、Smalltalkなどの言語には当てはまりません。しかし、主流の言語の大半では、論理的および算術的な優先順位は完全に標準化されています。

私の考えでは：

はい長所：

• 操作の順序は明示的です。
• 操作の順序を理解していない将来の開発者からあなたを守ります。

はい短所：

• コードが乱雑で読みにくいことがあります

NO賛否ません。

• ？

NO短所ません。

• 操作の順序は暗黙的です
• 開発者は、操作の順序を十分に理解していないと、コードの保守性が低下します。

余分な括弧を含めることに賛成または反対する議論はありますか？実用的な経験は、読みやすさのためにそれらを含める価値があることを示唆していますか？それとも、開発者が実際に座って自分の言語の基本に自信を持つ必要があるという兆候ですか？

他の誰も私のコードを再度見る必要がなければ、私は気にしません。

しかし、私の経験から：

• 私は時々コードをもう一度見ます（それを書いてから数年後）
• 他の人は時々私のコードを見る
  • または、拡張/修正する必要があります！
• 私も他の人も、それを書いているときに私が思っていたことを正確に覚えていない
• 不可解な「文字数を最小化する」コードを書くと読みにくくなる

私はほとんど常にこれを行います。なぜなら、私はすぐに読む能力を信頼し、他の何よりも括弧で多くの小さな間違いを犯さないためです。

あなたの場合、私はほぼ確実に次のようなことをします：

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

はい、それはより多くのコードです。はい、代わりに派手なブール演算子を実行できます。いいえ、1年以上先のコードをスキミングして派手なブール演算子を読み間違える可能性はありません。AND / ORの優先順位が異なる言語でコードを記述していて、これを修正するためにジャンプする必要がある場合はどうなりますか？「ああ、この賢いささいなことを思い出します。去年書いたときにカッコを入れる必要はありませんでした。今はいいことを覚えています！」それが起こった場合（または、さらに悪いことに、この賢さを知らなかった、または "fix asap"タイプの状況に陥った他の誰か）？

（）で区切ると、後で簡単に理解して理解できるようになります。

一般的なケース

C＃では、乗算と除算が加算と減算よりも優先されます。

それでも、コードベース全体に共通のスタイルを強制するツールであるStyleCopには、十分に明確ではないコードによるバグのリスクを軽減するという追加の目標があり、ルールSA1407があります。このルールは、次のようなコードで警告を生成します。

var a = 1 + 2 * 3;

結果が7であり9、ではないことは明らかですが、StyleCopは括弧を付けることを提案しています：

var a = 1 + (2 * 3);

あなたの特定のケース

特定のケースでは、使用する特定の言語のORと比較してANDの優先順位があります。

これは、すべての言語の動作ではありません。他の多くの人は、ANDとORを等しく扱います。

主にC＃で作業する開発者として、最初にあなたの質問を見て、あなたが書いたものを読まずにコードを読んだとき、私の最初の誘惑は2つの式が同じではないとコメントすることでした。うまくいけば、コメントする前に質問全体を読んだことがあります。

この特殊性と、一部の開発者がANDとORの優先順位が同じであると信じるリスクがあるため、括弧を追加することがさらに重要になります。

あなたが賢いことを示す目的でコードを書かないでください。言語のあらゆる側面に精通していない人も含めて、読みやすさを目標にコードを記述してください。

誰もが言ったように、式を読みやすくするたびに括弧を使用します。ただし、式が複雑な場合は、部分式に新しい関数を導入することをお勧めします。

それとも、開発者が実際に座って自分の言語の基本に自信を持つ必要があるという兆候ですか？

単数形で厳密に言語を使用する場合は、おそらく。さて、古いものから最新のものまで、コンパイルからスクリプト作成からSQL、先月発明したDSLまで、あなたが知っているすべての言語を使いましょう。

見ずに、これらの各言語の正確な優先規則を覚えていますか？

「必要でない場合でも、論理ステートメントで括弧を使用する必要があります。」

はい、2人が役に立つと思うからです。

• 次のプログラマーは、知識、能力、またはスタイルが異なる場合があります

• 後日このコードに戻る未来のあなた！

複雑な条件式は「ブール代数」であり、代数とまったく同じように見えるようにいくつかの方法で記述します。代数には必ず括弧を使用しますよね。

本当に便利なルールは否定ルールです：

!(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

基本的に、条件式はまだ単なる代数式であり、括弧を明確に使用することで、「この式を単純化または拡張する」という古い概念を含め、すでに知っているさまざまな代数ルールをより簡単に式に適用できます。

たとえそれがオプションであっても、括弧を使用します。それは、コードを作成する人とそのコードを見る準備ができている人にとって、すべての人にとってよりよく理解するのに役立つからです。あなたの場合、ブール演算子でさえも最初はうまくいくかもしれませんが、すべての場合に役立つとは言えません。だから私はそれを必要とするかもしれない任意の条件で、またはオプションでユーザー括弧を好む。

はい。コードがより明確になると思われる場合は、どのような場合でも使用する必要があります。コード内のコメントを読まなくても他の人が理解できるように、コードは十分に明確でなければなりません。したがって、括弧と中括弧を使用することをお勧めします。また、それはあなたの会社/チームの特定の実践に依存するかもしれないことを覚えておいてください。1つのアプローチを維持し、混在させないでください。