Checkstyle は、次の点について不満を述べています。
return (null == a ? a : new A());
かっこは不要だと言います。
ステートメントは確かにそれらがなくても問題なく機能しますが、それらが存在する方がはるかに読みやすいように見えます---それ以外の場合、私がそれを読んでいると、私は見る傾向があります:
return null
最初に残りを検討するために一時停止する必要があります
== a ? a : new A();
一部、私の脳はすでに1つの道をたどっているので。
さらに、括弧でグループ化されていない限り、三項演算子を見るたびに同じことをする傾向があります。
だから：三項の周りのかっこは事実上の標準であるべきですか？それらをそこに置かない理由はありますか？
まあ、checkstyleは正しいです、括弧は実行には役に立ちません。しかし、実行に役に立たないということは、コードをよく読むために役に立たないという意味ではありません。読むほうが理にかなっている場合は、そのままにしておく必要があります。
このコードにはこれ以上括弧は必要ないと思います:
int number = (myBoolean)? 1 : 2;
しかし、あなたの場合、returnキーワードとブール値が式であるという事実により、ステートメントの読み方が変わる可能性があります。
return ステートメントを読むと、'return' と ';' の間のすべてがわかる。が返されるので、あなたが読んだと主張するように、コードサンプルを return null の後にいくつかのシンボルが続くように読む方法はありません。
おそらく、解析テクニックを読んでおくと、私のようにそれを理解するのに役立つかもしれません. そうは言っても、何年にもわたっていくつかのパーサーをまとめてきましたが、解析手法についてはあまり読んでいません。
不要な括弧は常に削除します。私はJavaの演算子の優先順位をよく知っているので、コードの理解には役立ちません。よくわからないときは、括弧を追加して、IDEA がそれらが冗長であると通知するかどうかを確認するのを待ちます。次に、それらを削除し、発見したばかりの優先順位規則を記憶にコミットしようとします。
私が継承したコードベースでは、他の理由で不十分なコード領域に冗長な括弧が最も多く見られる傾向があるため、この 2 つを関連付けます。
いいえ、事実上の標準であってはなりません。括弧なしの方が好きです。
それらをそこに置く唯一の理由は、評価の順序を強制するため、または紛らわしい線を明確にするためだと思います。
一般的に、いいえ。
三項 (条件とも呼ばれます) 演算子またはそのセクションを括弧で囲む必要はありません。これは、演算子の優先順位が演算の順序 (論理演算子のすぐ下、代入の上) で非常に低いためです。完全な表については、以下のリンクを参照してください。
したがって、そのような不要な括弧はコードを視覚的に混乱させ、プログラマー側の理解の欠如を明らかにすると主張することができます.
三項またはその前後に括弧を使用する必要がある例外は次のとおりです。
三項が複数の行に値するほど複雑な場合。次に、セミコロンの自動挿入を防ぐために、ステートメントを括弧で囲むことができます。
三項が別の三項内にネストされている場合。
MDN も参照してください:
どちらのオプションも正しいです。チームが使用するものを使用するか、単独で作業している場合は好きなものを使用してください。
IIRC デフォルトでは、checkstyle は Sun の (rip) スタイル ガイドラインを使用するため、標準スタイルに準拠したい場合は、それを聞いて括弧を削除してください。
あなたの質問の根拠はコードを読む行為に関係しているので、その観点から質問に取り組みます。
いわゆる「速読」トレーニング プログラムの基本原則の 1 つは、テキストを単語ごとに順番に読むのではなく、テキスト行の全体像を読者に理解させようとすることです。トークンをトークンごとに解析する行為であるかのように読む行為を扱うのではなく、完全な行の感覚を得るために、彼らの本からページを取り、コードから一歩下がって (文字通り必要であれば) 試みるかもしれません。
または、スタイルを構成できるエディターを使用することもできます。三項演算子を別の色にして、目立つようにすることもできます。たとえば、Notepad++ には、他の多くのエディターと同様に、これを行う組み込みのテーマが多数あります。