ブール割り当てのベストプラクティス[終了]

別の開発者から引き継いだプログラムで、次の条件に遭遇しました。

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

このコードは冗長で見苦しいと思うので、比較に基づいて単純なブール割り当てと考えていたものに変更しました。

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

これを見ると、私のコードをレビューしている人が、私の変更は機能的には正しいものの、他の人がそれを見て混乱させるかもしれないとコメントしました。彼は、三項演算子を使用すると、この割り当てがより明確になると信じていますが、私はより冗長なコードを追加するのは好きではありません：

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE) ? true : false;

彼の推論は、他の開発者があなたがやったことを正確に止めて困惑させなければならないなら、最も簡潔な方法で何かをすることは価値がないということです。

ここでの本当の問題は、ブール値に値を割り当てるこれら3つの方法のうち、どれがobj.NeedsChange最も明確で保守しやすいのかということです。

私は2を好むが、私はそれに少し調整をするかもしれない：

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

私にとって、括弧は行を解析しやすくし、比較結果を割り当てていること、そして二重割り当てを実行していないことを一目で明らかにします。なぜそうなるのかはわかりません（かっこで実際に二重の代入を妨げるような言語は考えられません）が、レビュアーを満足させる必要がある場合は、おそらくこれは許容できる妥協案でしょう。

バリアント1は簡単に理解できますが、それが唯一の利点です。このように書く人は、ブール値が何であるかを本当に理解しておらず、他の多くの点で同様の幼児コードを書くことになると自動的に仮定します。

バリエーション2は、私がいつも書くもので、読むことを期待しているものです。そのイディオムに混乱している人は、ソフトウェアのプロのライターであってはならないと思います。

バリアント3は、1と2の両方の短所を兼ね備えています。

いつでもコードは、「これが何をしているのか」をトリガーする必要があるよりも複雑です。読者の匂い。

たとえば、最初の例では、「削除されたある時点でif / elseステートメントに他の機能がありましたか？」

例（2）はシンプルで明確で、必要なことを正確に行います。私はそれを読み、コードが何をするのかすぐに理解します。

（3）の余分な毛羽立ちにより、著者が（2）の代わりになぜそのように書いたのか疑問に思うでしょう。理由があるはずですが、この場合はそうではないようですので、構文はそこに存在しない何かを示唆しているため、まったく役に立たず、読みにくくなります。存在するもの（何もない場合）を学習しようとすると、コードが読みにくくなります。

Variant 2とVariant 1は、一連の明白で単純なリファクタリングによって関連付けられていることが簡単にわかります。

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

ここでは、不必要なコードの重複があり、割り当てを除外できます。

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE)
{
    true
}
else
{
    false
}

またはより簡潔に書かれた：

obj.NeedsChange = if (obj.Performance <= LOW_PERFORMANCE) true else false

条件がtrueの場合、trueが割り当てられ、条件がfalseの場合、falseが割り当てられることがすぐにわかるはずです。IOWは、単純に条件の値を割り当てます。つまり、

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE

バリアント1と3は、比較の戻り値が何であるかを理解していない人によって書かれた典型的なルーキーコードです。

あなたのプログラミングは「コードを維持する人があなたの住んでいる場所を知っている暴力的なサイコパスであるかのように」暗黙的で暗黙的である傾向がありますが、あなたのサイコの後継者が有能であるいくつかの基本的な事柄を仮定することができます。

それらの1つは、彼が使用している言語の構文です。

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;

C / C ++ / C＃/ Java / Javascriptシンタックスを知っている人なら誰でも非常に明確です。

また、8行よりもはるかに読みやすくなっています。

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.NeedsChange = false;
}

間違いを起こしにくい

if (obj.Performance <= LOW_PERFORMANCE)
{
    obj.NeedsChange = true;
}
else
{
    obj.Needschange = false;
}

そして、あたかも言語の構文を忘れているかのように、不要な文字を追加するよりも優れています。

obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE ? true : false;

obj.NeedsChange = (obj.Performance <= LOW_PERFORMANCE);

多くの言語のCライクな構文には、多くの誤りがあると思います：一貫性のない操作の順序、一貫性のない左/右の結合、記号のオーバーロードの使用、ブレース/インデントの複製、三項演算子、中置記法など

しかし、解決策は、独自の独自バージョンを発明することではありません。誰もが自分自身を作成するので、その方法は狂気にあります。

一般に、Real World ^TMコードを読み取り不能にする一番の理由はその量です。

病的でない200行のプログラムと、まったく同じ1,600行のプログラムの間では、短いプログラムの方がほとんど常に解析と理解が容易です。いつでもあなたの変更を歓迎します。

ほとんどの開発者は、2番目のフォームをひと目で理解できます。私の意見では、第1の形式のような単純化は単に不要です。

次のようなスペースとブレースを追加することで、読みやすくすることができます。

obj.NeedsChange =    obj.Performance <= LOW_PERFORMANCE;

または

obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );

ジェイコブ・ライレが述べたように。