三項演算子は有害と考えられますか？[閉まっている]

たとえば、このワンライナーを好むだろうか

int median(int a, int b, int c) {
    return (a<b) ? (b<c) ? b : (a<c) ? c : a : (a<c) ? a : (b<c) ? c : b;
}

または複数のreturnステートメントを含むif / elseソリューションですか？

?:適切な場合と適切でない場合 初心者に教えたり隠したりするべきですか？

三項演算子は悪ですか？

いいえ、それは祝福です。

いつですか？：適切ですか？

とても単純なもので、多くの行を無駄にしたくない場合。

それはいつですか？

コードの読みやすさと明確さが損なわれ、注意が不十分なためにミスが発生する可能性が高くなった場合（たとえば、例のように多くのチェーン演算子を使用した場合）。

リトマステストは、長い目で見ればコードの読み取りと保守が容易であることを疑い始めるときです。それをしないでください。

ネストされていない3項演算子（つまり、1回だけ使用されるステートメント）は問題ないと思いますが、2つ以上をネストしている場合、読みにくくなります。

いつですか？：適切

• コードがより簡潔で読みやすくなるとき。

それはいつですか？

• コードが読めなくなるとき。
• コードを保守しなければならない人ではなく、ReSharperのようなリファクタリングツールを喜ばせるためだけにやっているなら

三項式内にロジックまたは関数呼び出しがある場合、それを見るのが恐ろしくなります。

（私が思うに）誰も指摘していない違いの1つは、if-elseが値を返せないのに対し、三項演算子は返せるということです。

F＃から来て、三項演算子を使用してパターンマッチングを模倣することが好きな場合があります。

match val with
| A -> 1
| B -> 3
| _ -> 0

対

return val == A ? 1 : 
       val == B ? 3 : 
       0;

有効な使用例（IMHO）：

printf("Success in %d %s\n", nr_of_tries, (nr_of_tries == 1 ? "try" : "tries"));

これにより、2つの個別のprintステートメントを使用するよりもコードが読みやすくなります。入れ子になった例は次のとおりです：（わかりやすい？はい：いいえ）

絶対に悪ではありません。実際、それは純粋で、if-then-elseはそうではありません。

Haskell、F＃、MLなどの関数型言語では、悪と見なされるのはif-then-elseステートメントです。

その理由は、命令型if-then-elseステートメントのような「アクション」では、変数宣言をその定義から分離する必要があり、関数に状態を導入するためです。

たとえば、次のコードでは：

const var x = n % 3 == 1
    ? Parity.Even
    : Parity.Odd;

対

Parity x;
if (n % 3 == 1)
    x = Parity.Even;
else
    x = Parity.Odd;

最初のものには、短くなること以外に2つの利点があります。

1. x は定数であるため、バグが発生する可能性ははるかに低く、2番目の方法では不可能な方法で最適化できます。
2. 型は式によって明確にされるため、コンパイラーはそれxがtypeである必要があると簡単に推測できますParity。

紛らわしいことに、関数型言語では、三項演算子はしばしばif-then-elseと呼ばれます。Haskellでは、と言うかもしれませんx = if n mod 3 == 1 then Odd else Even。

その特定の表現は私の目を傷つけます。メンテナンスできないので、それを使用した私のチームの開発者を非難します。

三項演算子は、うまく使えば悪ではありません。それらは単一行である必要さえありません。適切にフォーマットされた長いものは、非常に明確で理解しやすいものです。

return
      ( 'a' == $s ) ? 1
    : ( 'b' == $s ) ? 2
    : ( 'c' == $s ) ? 3
    :                 4;

私は同等のif / then / elseチェーンよりもそれが好きです：

if ( 'a' == $s ) {
    $retval = 1;
}
elsif ( 'b' == $s ) {
    $retval = 2;
}
elsif ( 'c' == $s ) {
    $retval = 3;
}
else {
    $retval = 4;
}

return $retval;

それらを次のように再フォーマットします。

if    ( 'a' == $s ) { $retval = 1; }
elsif ( 'b' == $s ) { $retval = 2; }
elsif ( 'c' == $s ) { $retval = 3; }
else                { $retval = 4; }

return $retval;

条件と割り当てが簡単に調整できる場合。それでも、私はそれが短く、条件と割り当ての周りにそれほどノイズがないので、三元バージョンを好みます。

VS.NETのReSharperはif...else、?:オペレーターに置き換えることを提案する場合があります。

ReSharperは、条件/ブロックが特定の複雑度レベルを下回っている場合にのみ提案するようif...elseです。

これは、if / elseの組み合わせと同じように見栄えがするように再フォーマットできます。

int median(int a, int b, int c)
{
    return
        (a<b)
        ?
            (b<c)
            ? b
            :
                (a<c)
                ? c
                : a
        :
            (a<c)
            ? a
            :
                (b<c)
                ? c
                : b;
}

しかし、問題は、実際に何が起こるかを表すためのインデント権を取得したかどうか、私には本当にわからないことです。:-)

悪であるとはほど遠く、三項演算子は天の恵みです。

• ネストされた式で決定を行う場合に最も便利です。典型的な例は関数呼び出しです：

  printf("I see %d evil construct%s in this program\n", n, n == 1 ? "" : "s");
  

• あなたの特定の例では、三項はaの下のトップレベルの式であるため、ほとんど無償returnです。returnキーワード以外のものを複製することなく、条件をステートメントレベルに引き上げることができます。

注：中央値の特定のアルゴリズムを読みやすくするものはありません。

1. 「悪」の議論は別として、私の経験では、プログラマーの三項演算子の使用と、コードベース全体の読み取り、追跡、および維持が困難である可能性（完全に文書化されていない場合を除く）の間に高い相関があることがわかりました。プログラマが自分のコードを理解できる人よりも数文字の1〜2文字の行を保存することに関心がある場合、3項ステートメントを理解する小さな混乱は通常氷山の一角です。

2. 三項演算子は、s ** tがハエを引き付けるように、マジックナンバーを引き付けます。

特定の問題を解決するためにオープンソースライブラリを探していて、そのライブラリの候補に元のポスターの三項演算子などのコードを見た場合、警告ベルが頭の中で鳴り始め、先に進むことを検討し始めました借りる他のプロジェクトに

ここでは、それは場合の例だある悪：

oldValue = newValue >= 0 ? newValue : oldValue;

紛らわしくて無駄です。コンパイラーは2番目の式（oldValue = oldValue）を最適化できますが、なぜ最初にコーダーがこれを行ったのですか？

もう一つのすごい：

thingie = otherThingie != null ? otherThingie : null;

一部の人々は単にコーダーになることを意図していない...

グレッグは、同等のifステートメントは「うるさい」と言います。うるさく書いた場合です。ただし、次のように記述できる場合は同じです。

if ('a' == $s) return 1;
if ('b' == $s) return 2;
if ('c' == $s) return 3;
return 4;

これは3項よりもノイズが多いわけではありません。三項の近道かしら？すべての式が評価されますか？

悪の？見て、彼らはただ違うだけです。

ifステートメントです。(test ? a : b)式です。それらは同じものではありません。

値を表現する式が存在します。アクションを実行するためのステートメントが存在します。式はステートメント内に表示できますが、その逆はできません。したがって、合計の項やメソッドの引数など、他の式内で3項式を使用できます。する必要はありませんが、望むならできます。それには何の問題もありません。一部の人々はそれが悪だと言うかもしれませんが、それは彼らの意見です。

三項式の値の1つは、trueとfalseの両方のケースを処理できるようにすることです。ifステートメントはしません。

読みやすさを心配している場合は、読みやすい形式にすることができます。

どういうわけか「悪」がプログラミング用語に忍び込んできました。誰が最初に落としたのか知りたいです。（実際、私は容疑者を持っています-彼はMITにいます。）私はむしろ、この分野での価値判断の客観的な理由があり、人々の好みや名前を呼ぶだけではありません。

場所があります。私は、開発者のスキルレベルがひどいものからウィザードのものまで、多くの企業で働いてきました。コードを維持する必要があり、私は永遠にそこにいないので、そこに属するように見えるように書きます（私のイニシャルでコメントを見ずに、あなたができることは非常にまれです変更した場所を確認するために作業したコードを見てください）、そして自分よりもスキルの低い人がそれを維持できることを確認してください。

三項演算子は素晴らしくて格好いいように見えますが、私の経験では、コードの行を維持するのはほぼ不可能です。私の現在の雇用主には、ほぼ20年間出荷されている製品があります。その例はどこにも使用しません。

三項演算子は悪だとは思いません。

しかし、ここで私が困惑した落とし穴があります。私は多くの（10歳以上）Cプログラマーでしたが、1990年代後半にWebベースのアプリケーションプログラミングに移行しました。Webプログラマーとして、すぐに三項演算子を持つPHPに出会いました。PHPプログラムにバグがあり、ネストされた三項演算子を含むコード行に最終的に辿りました。PHPの三項演算子は左から右に関連付けられていますが、Cの三項演算子（私が慣れていた）は右から左に関連付けられています。

コードの見栄えを悪くするものはすべて悪です。

コードをクリーンにするために3進数を使用する場合は、必ず使用してください。時々phpのように、インライン置換を行うのは素晴らしいことです。例えば

"Hello ".($Male?"Mr":"Ms")." $Name

それは数行を節約し、それはかなり明確ですが、あなたの例は明確にするために少なくともより良い書式設定が必要であり、三項は複数行には本当に良くないので、if / elseを使用することもできます。

言えますか？私は、三項演算の悪のこの特定のアプリケーションを見つけることができません。

1. それが実行する操作は非常に簡単であり、一度それをトラフにすると、いくつかのバグが出る可能性はほとんどありません。
2. それが何をするかは、関数名に明確に記載されています。
3. 非常に明白で、将来的には明らかに改善されない何かのために> 1行を取得します（マジックメディアンアルゴリズムが今まで検出されなかった場合を除く）。

慈悲を持ってください、私の評判はすでにかなり哀れです。

最大の勝利：アクションのターゲットが1つであることを示します。

if ( $is_whatever )
    $foo = 'A';
else
    $foo = 'B';

フォローできるコードパスは2つあり、読者はどちらの変数が設定されているかを注意深く読む必要があります。この場合、変数は1つだけですが、読者はそれを理解するためにさらに読む必要があります。結局のところ、それはこれだったかもしれません：

if ( $is_whatever )
    $foo = 'A';
else
    $bar = 'B';

三項演算子を使用すると、設定されている変数が1つだけであることは明らかです。

$foo = $is_whatever ? 'A' : 'B';

最も低いレベルでは、最も基本的なのはDRY（Do n't Repeat Yourself）原則です。$foo一度しか指定できない場合は、指定してください。

If ... then ... elseは条件を強調する傾向があり、そのため条件付きで実行される操作を強調しません。

三項演算子は逆であり、条件を隠す傾向があり、実行される操作が条件自体よりも重要な場合に有用です。

一部の言語では、1つはステートメントであり、もう1つは式であるため、C ++でconstを条件付きで初期化するため、あまり互換性がないという小さな技術的な問題があります。

適切な場合と適切でない場合

同種の人々のために開発する場合、問題はないと思いますが、異なるレベルを処理する人々に対処しなければならない場合、この種のonelinersはコードにさらに複雑なレベルを導入するだけです。したがって、この問題に関する私のポリシーは、コードを短くして123123回説明するのではなく、コードを明確にし、説明しないことです。

初心者に教えたり隠したりするべきですか？

私は初心者に教えられるべきではなく、むしろ必要が出てきたときにそれを理解することを好むので、必要なときにだけ使用され、ifが必要なたびに使用されることはありません。

IMO、演算子自体は悪ではありませんが、C（およびC ++）で使用される構文は非常に簡潔です。IMO、Algol 60の方が優れていたため、次のようになりました。

A = x == y ? B : C;

次のようになります（ただし、一般にCのような構文に固執します）。

A = if (x==y) B else C;

それでも、過度に深いネストは読みやすさの問題につながる可能性がありますが、少なくともA）プログラミングを行った人なら誰でも簡単なものを理解でき、B）それを理解している人はかなり深いネストをかなり簡単に処理できます。OTOH、LISP（たとえば）では、a condは3項ステートメントに非常に似ています-ステートメントのセットではなく、値を生成する単一の式です（そして、LISPの大部分はそのようなものです。） ）

定期的に 600〜1200行のメソッドを記述するショップは、3進法が「理解しにくい」と言ってはいけません。コードブランチを評価するために5つの条件を定期的に許可しているショップでは、3進数で具体的に要約された条件が「読みにくい」とは言わないでください。

いつですか？：適切で、いつではないですか？

• パフォーマンスが向上しない場合は、使用しないでください。コードの可読性に影響します。
• 一度使用して、ネストしないでください。
• デバッグが難しくなります。

初心者に教えたり隠したりするべきですか？

重要ではありませんが、「初心者」が学習するのに複雑すぎないため、意図的に隠すべきではありません。

あなたの例では：

def median(a, b, c):
    if a < b < c: return b
    if a < c < b: return c
    if b < a < c: return a
    if b < c < a: return c
    if c < a < b: return a
    if c < b < a: return b

非常に読みやすく、明らかです。<<の間の変数は戻り値です。

更新

同じですが、コードの行が少なくなります。まだシンプルだと思います。

def median(a, b, c):
    if b<a<c or c<a<b: return a
    if a<b<c or c<b<a: return b
    if a<c<b or b<c<a: return c

constにも必要です

const int nLegs  = isChicken ? 2: 4 ;