プログラマーは演算子の優先順位を完全に認識している必要がありますか? 中括弧を使用して式をグループ化しても問題ありませんよね? 私は常にブレースを使用して安全を確保しています。そして、優先的に質問されると、なかなか答えられません。
18 に答える
非常に一般的なオペレーターの場合 - はい、知っておく価値があります。演算子の優先順位に依存するすべてのものを括弧で囲むと、コードが読めなくなります (または Lisp と簡単に混同されます)。
よりあいまいな演算子については、私は明示的にそれらの学習を避けました。他の開発者が知っていると合理的に期待できないほど多くのことを当然のことと考え始めると、私は簡単に読めるが他の誰もできないコードを書き始めます。最も良い例はシフト演算子です。これらのどれが括弧なしで同じように扱われるかはわかりませんが(確かに-私はインクリングを持っています)、どちらがより明確であるかは絶対に確信しています:
int x = (y << shift) + offset;
また
int x = y << (shift + offset);
はい、演算子の優先順位を理解することが重要です。ただし、括弧を使用して意図を完全に明確にすることには価値があると思います。読みやすさと保守性に役立ちます。
何年も前に、C の次の優先順位表を見ました。
- 掛け算と割り算は、足し算と引き算の前に行われます。
- 括弧を使用します。
これは少し単純化しすぎていますが、正しい考えを持っています。
最も一般的な算術演算子を除いて、チート シートを使用します。少しでも難しい場合は、明示的な括弧を使用して意図を明確にします。
私が優先順位を暗記するよりも書面によるガイドを使用する方が好きな理由は、微妙に異なるルールを持つ複数の言語で作業することが多いからです。最も一般的な演算子以外のものを暗記すると、記憶に頼りすぎるとエラーが発生する可能性があります。
あなたはそれを理解する必要がありますが、他の人が理解できると思い込んではいけません。優先順位を明示するために、常に括弧を使用します。
どこでも括弧を使用していない人が書いたコードを読めるように理解する必要があります。
「常に中かっこ」が良い経験則だとは思いません。括弧が多すぎるコードは、必要以上に読みにくくなります。お気に入り:
(a * b) + c
ばかげているだけです。どこかにバランスがあり、それを見つけることが課題です。他の多くのことと同様に、常識を適用することです。
実際には:そうではありません。演算子の優先順位を知る必要があるほど複雑な場合は、式をチャンクに分割する必要があります。また、括弧はあなたを救います!
専門的に: 選択した言語の順序を習得するのにそれほど時間はかかりません。また、他の人のコードを読むときにも役立ちます。他に何もない場合は、キューブウォールのチートシートに保管してください.
クイック。T-SQL で優先順位が高い: AND 対 OR。
SELECT c.Name
FROM [Customer] c LEFT JOIN [Order] o
ON c.CustomerKey = o.CustomerId
WHERE c.Name like 'B%'
OR c.Name like 'Z%'
AND o.CustomerId is NULL
これらの演算子の優先順位をその優先順位に依存するところまで学習すると、次のいずれかの運命になります。
- それらを自分で間違って使用してください。
- これらの演算子を学習せず、コードを読み取ることができない他のユーザーの過ちに苦しむことになります。
基本的なこと (たとえば、足し算や引き算よりも高い割り算や掛け算) は知っていますが、もっと難解なことを調べる必要があります。
私は通常、意図を明確にするために括弧を使用します。読みやすく、誤った仮定によるエラーを回避できると思います。
確かに害はありませんし、他の人が書いた優先順位の微妙なコードを読むのに役立ちます.
ただし、実際には、コードを保守する人が同じスキルを持っていると想定しない方がよいでしょう。そのため、このコードを読むことができるはずですが、相互作用をあまり利用するコードを書きたくない場合があります。あちこちにいくつかの余分な括弧が必要になるとしても、紛れもない構造を使用することをお勧めします。
私はこれについてあなたと一緒です。中括弧を使用して優先順位を明示することは、常に良い考えです。コードが読みやすくなり、意図が明確になります。
そうは言っても、他の人のコードを保守している場合に備えて、演算子の優先順位に関する情報を検索する場所を知っておく必要があります。
演算子の優先順位の概念について知っていると仮定すると(数学の授業で誰もが知っていると思います)、読者側の知識は想定しません...
...常識を除いて: 指摘されているように、 のような式はa * b + c
、数学の授業の知識を使用して理解できます。のようなブール式a < 4 && a > 0
は理解できます。なぜなら、比較をより厳密にバインドする方が論理的だからです&&
。
一方、ビット単位の演算子と通常の算術演算を混在させることには常識がないため、そこでは括弧を使用することをお勧めします。&&
また、 overの優先順位についても常識がない||
(またはその逆か?) ため、そこでも括弧を使用します。
私はいくつかの言語 (C、C++、perl、bash、そしてときどき TCL/TK のダッシュ) で作業しているため、優先順位規則を 100% 把握していません。何年にもわたってさまざまな時期に、私はいくつかの異なるアセンブリ言語と、1 つまたは 2 つの非準拠コンパイラを使用してきました。
完全に詳細な優先順位規則を頭の中でまっすぐに保つことはできません。規則セットを頻繁に切り替えなければなりません。
基本的な優先ルールを理解することが重要だと思います。核心的な詳細を知ることは、時間の価値がないと思います。主に、優先順位があいまいな場合は、単純な括弧のセットで解決できるためです。第二に、誰もがそれらを知っているわけではなく、グループ内のユーザーがコードを読めるようにすることが最善であるためです。
大学時代、私はすべての優先ルールを暗記していました。現実の世界に入ると、ほとんどの人が彼らを心から知らなかったことがわかりました。いくつかの優先ルールに依存する有効なコードをチェックインすると、一貫して同じフィードバックが得られました。
はい:
- * / + -
- && || そして、または
いいえ/多分:
- << >> & | ^
書くときに自分をだますのはとても簡単a == a & some_flag
です。
わかりやすくするために括弧と一時記号を使用して、優先順位のルールを学習しないことをお勧めしますが (覚えておいてください: コードは人間が読むことを意図しています)、演算子の優先順位表が役立つ場合があります。
いいえ!
優先順位がわからない場合は、コードを読んでいる他の人がコードを間違って解釈する可能性があります。
よくわからない場合は
( .. )関連するコードのビットがあれば、あなたにも他の人にもあいまいさはありません。
3 つ目のオプションがあります。それらのルールをすべて暗記したり、括弧を使用してすべてを確認したりするのではなく...
式が長すぎて最初に何が起こるかはっきりしない場合は、中間結果に一時変数を使用して、複数の行に分割します。次に、かっこを散らかさずにわかりやすくし、一時変数にわかりやすい名前を使用して、物事をさらに明確にすることができます。