Java 演算子の優先順位の誤解は、よくある質問と微妙なエラーの原因です。Java 言語仕様でさえ、「コードはこの仕様に決定的に依存しないことをお勧めします」と述べていることに興味をそそられました。JLS §15.7賢いよりも明快な方が好きですが、この分野で役立つガイドラインはありますか?
このトピックに関する多くのリソースを次に示します。
追記・修正大歓迎です。
「実世界」に関する限り、おそらく次のように言うのが妥当でしょう。
*/
したがって、 vsの特定のケースとは別に、+-
意図した優先順位を明示的に定義するためにブラケットを使用するだけです。
関連するもう 1 つのバグの原因は、丸め誤差の蓄積方法です。演算子の優先順位の問題ではありませんが、算術的に同等な方法でオペランドを並べ替えた後に異なる結果が得られると、驚きの原因になります。これは、David Goldberg のWhat Every Computer Scientist Should Know About Floating-Point Arithmeticの sun.com バージョンです。
引用 ( Java 言語仕様 §15.7から) は、 Evaluation Orderのコンテキストで読む必要があります。hereで説明したように、そのセクションは評価順序に関するものであり、演算子の優先順位(または結合性) とは関係ありません。
優先順位と結合性は、式ツリーの構造(つまり、どの演算子がどのオペランドに作用するか) に影響を与えますが、「評価順序」は、式が評価されるときに式ツリーがトラバースされる順序に影響を与えるだけです。一部のサブ式に、他のサブ式の結果 (または副作用) に影響を与える副作用がない限り、評価順序 (または「走査順序」) は効果がありません。
たとえば、最初に x==1 の場合++x/++x
、Java の評価順序は左から右であるため、式は 2/3 (0 に評価されます) として評価されます。Java の評価順序が右から左の場合、x は分子が評価される前に 2 回インクリメントされ、式は 3/2 (1 に評価される) として評価されます。評価順序が定義されていない場合、式はこれらの結果のいずれかに評価された可能性があります。
問題の引用は、その文脈とともに...
Java プログラミング言語は、演算子のオペランドが特定の評価順序 (左から右) で評価されるように見えることを保証します。
コードがこの仕様に決定的に依存しないことをお勧めします。各式がその最も外側の操作として多くても 1 つの副作用を含む場合、コードは通常より明確になります。
...読者が Java の評価順序の左から右に依存することを思いとどまらせます(上記の例のように)。不要な括弧を奨励しません。
編集: リソース:各優先レベルが推論される構文文法を含む JLS のセクションへのインデックスとしても機能するJava 演算子の優先順位テーブル。
JLSは、明示的な演算子優先順位テーブルを提供しません。これは、 JLSがさまざまな演算子を記述するときに暗示されます。たとえば、の文法ShiftExpression
は次のとおりです。
ShiftExpression:
AdditiveExpression
ShiftExpression << AdditiveExpression
ShiftExpression >> AdditiveExpression
ShiftExpression >>> AdditiveExpression
これは、加法演算子(+
および-
)が左結合シフト演算子(<<
、>>
および>>>
)よりも優先順位が高いことを意味します。
また、論理的な && と || を忘れないでください。はショートカット演算子です。次のようなものは避けてください。
sideeffect1() || sideeffect2()
sideeffect1() が true と評価される場合、sideeffect2() は実行されません。&& と false についても同様です。これは優先順位と完全に関連しているわけではありませんが、これらの極端なケースでは、結合性も重要な側面になる可能性があり、通常はまったく無関係です (少なくとも私に関する限り)。
これの真実は、「ほとんどのプログラマー」が「他のほとんどのプログラマー」が演算子の優先順位を知らない、または覚えていないと考えているように私には思えます。かっこ」、それを「明確にする」ためだけに。この 3 年生のことを思い出すことが本当の問題かどうかは別の問題です。これはすべて完全に時間の無駄であり、何かが事態を悪化させるとすれば、同様に議論の余地があります。私自身の見解では、可能な限り冗長な構文は避けるべきであり、コンピューター プログラマーは自分がプログラミングしている言語を知っているべきであり、おそらく同僚に期待を抱かせるべきだというものです。