C# の三項演算子の結合性 - 信頼できますか?

StackOverflow https://stackoverflow.com/questions/1763543

質問

ああ、単に良い三項虐待が好きなだけではないですか?:) 次の式を考えてみましょう。

true ? true : true ? false : false

今完全に当惑している皆さんのために、これは次のように評価されると言えます。 真実. 。つまり、これは次と同等です。

true ? true : (true ? false : false)

しかし、これは信頼できるのでしょうか？状況によっては次のような事態にはならないと断言できますか?

(true ? true : true) ? false : false

いくつかは言うかもしれません - そうですね、括弧を追加するか、丸括弧をまったく使用しないでください。結局のところ、三項演算子が悪であることは周知の事実です。

確かにその通りですが、状況によってはそれが実際に意味をなす場合もあります。興味のある人のために、私は一連のプロパティによって 2 つのオブジェクトを比較するコードを作成しています。このようにコールドで書くとかなり良いでしょう:

obj1.Prop1 != obj2.Prop1 ? obj1.Prop1.CompareTo(obj2.Prop1) :
obj1.Prop2 != obj2.Prop2 ? obj1.Prop2.CompareTo(obj2.Prop2) :
obj1.Prop3 != obj2.Prop3 ? obj1.Prop3.CompareTo(obj2.Prop3) :
obj1.Prop4.CompareTo(obj2.Prop4)

明確かつ簡潔。ただし、最初のケースと同様に、三項演算子の結合性が機能するかどうかに依存します。括弧を付けるとスパゲッティができてしまいます。

それで、これはどこかに指定されていますか?見つかりませんでした。

役に立ちましたか？

解決

はい、あなたは（私が知っている）他の言語（C＃ではなく、すべてではないだけで（これに頼ることができます<のhref = "http://php.net/manual/en/language.operators.comparison.php一部の人々はそれを忌み嫌うが、条件演算子と「のrel =」PHP のを除いてnoreferrer "> ...図に行く））とあなたのユースケースは、実際にはかなり一般的である。

ECMA-334の関連するセクション（C＃の標準）は14.13§3である

  

条件演算子は、操作が右から左にグループ化されることを意味し、右結合です。   [例：フォームa ? b : c ? d : eの発現がa ? b : (c ? d : e)として評価されます。終わり   例

他のヒント

尋ねる必要がある場合は、しないでください。あなたのコードを読む人は誰でも、あなたと同じプロセスを何度も繰り返すだけで済みます。 どれでも コードを確認する必要があるとき。このようなコードのデバッグは楽しくありません。最終的には括弧を使用するように変更されるだけです。

Re: 「括弧を付けてすべてを書いてみてください。」

result = (obj1.Prop1 != obj2.Prop1 ? obj1.Prop1.CompareTo(obj2.Prop1) :
         (obj1.Prop2 != obj2.Prop2 ? obj1.Prop2.CompareTo(obj2.Prop2) :
         (obj1.Prop3 != obj2.Prop3 ? obj1.Prop3.CompareTo(obj2.Prop3) :
                                     obj1.Prop4.CompareTo(obj2.Prop4))))

説明:

  • "もし あなた 尋ねなければなりません、しないでください。」
  • 「読んでいる人は誰でも あなたの コード..."

プロジェクトで一般的な規則に従うことで一貫性が維持され、読みやすさが向上します。言語を知らない人も含め、誰にとっても読みやすいコードを作成できると考えるのは愚かな用事です。

ただし、プロジェクト内の一貫性を維持することは有益な目標であり、プロジェクトで受け入れられている規則に従わない場合は、実際の問題の解決を妨げる議論につながります。コードを読む人は、プロジェクトで使用されている一般的で受け入れられている規則を認識していることが期待されており、コードに直接取り組んでいる他の人である可能性さえあります。彼らがそれを知らない場合は、彼らはそれを学んでいることが期待されており、どこに助けを求めればよいかを知っている必要があります。

とはいえ、括弧なしで三項式を使用することがプロジェクトで一般的で受け入れられている規則である場合は、ぜひそれを使用してください。 あなたが尋ねなければならなかったということは、それがあなたのプロジェクトでは一般的ではないか、受け入れられていないことを示しています。 プロジェクト内の規則を変更したい場合は、明らかに明確な変更を行い、それを他のプロジェクト メンバーと話し合う内容としてマークし、次に進みます。ここで、それは括弧を使用するか、if-else を使用することを意味します。

コードの一部が賢いと思われる場合は、最後に考慮すべき点があります。

デバッグは、最初にコードを記述するよりも 2 倍困難です。したがって、コードをできるだけ賢く書いたとしても、定義上、コードをデバッグできるほど賢くはありません。— ブライアン W.カーニハン

コードの可読性を損なうカッコ主張は偽仮定です。私は、カッコ内の式がはるかに明確に見つけます。個人的に、私は読みやすさを向上させるために、複数行にわたる括弧および/または再フォーマットを使用します。複数の行の上に再フォーマットし、インデントを使用しても、括弧の必要性を回避することができます。そして、はい、あなたは協会の順序は右から左に、決定論的であるという事実に頼ることができます。これは、式が期待される形で、左から右に評価することができます。

obj1.Prop1 != obj2.Prop1
     ? obj1.Prop1.CompareTo(obj2.Prop1)
     : obj1.Prop2 != obj2.Prop2
           ? obj1.Prop2.CompareTo(obj2.Prop2)
           : obj1.Prop3 != obj2.Prop3
                  ? obj1.Prop3.CompareTo(obj2.Prop3)
                  : obj1.Prop4.CompareTo(obj2.Prop4);

MSDNを参照してください。 http://msdn.microsoft.com/en-私たち/ライブラリ/ ty67wk28％28VS.80％29.aspxする

は、「条件が真の場合、最初の式が評価され、結果となっている。。。falseの場合、第二式が評価され、その結果となり、これまでに評価される二つの表現の一つだけ」

x = cond1 ? result1
  : cond2 ? result2
  : cond3 ? result3
  : defaultResult;

対

if (cond1) x = result1;
else if (cond2) x = result2;
else if (cond3) x = result3;
else x = defaultResult;

私は、最初のものが好きです。

はい、あなたは条件演算子の結合性に依存することができます。そのマニュアルで、親切DCPによって提供されるリンクで、例を用い、「条件演算子が右結合である」と述べました。あなたが提案し、私と他の人が合意したと、あなたはそれに頼ることができるという事実は明確コードすることができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top