別の開発者から引き継いだプログラムで、次の条件に遭遇しました。
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;
彼の推論は、他の開発者があなたがやったことを正確に止めて困惑させなければならないなら、最も簡潔な方法で何かをすることは価値がないということです。
ここでの真の問題は、ブール値obj.NeedsChange
に値を割り当てるこれらの3つの方法のうち、最も明確で最も保守しやすいのはどれですか。
私は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は、比較の戻り値が何であるかを理解していない人によって書かれた典型的な新人コードです。
あなたのプログラミングは暗黙のうちに明示的な傾向があるはずですが、「あたかもあなたのコードを保守することになる人はあなたがどこに住んでいるかを知っている暴力的な精神病者であるかのように」、あなたcanあなたのサイコ後継者が有能であるいくつかの基本的な事柄を想定してください。
それらの1つは、使用している言語のsyntaxです。
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のような構文については、多くの誤りがあると思います:一貫性のない操作の順序、一貫性のない左/右結合性、オーバーロードされたシンボルの使用、中括弧/インデントの重複、3項演算子、インフィックス表記法など。
しかし、解決策は、独自の独自バージョンを発明することではありません。誰もが自分で作成するので、その方法は狂気です。
一般的には、現実世界を作る一番のことTM 読めないコードはその量です。
病理学的ではない200行のプログラムと、まったく同じ1,600行のプログラムの間では、短いプログラムの方がほとんど常に解析と理解が容易になります。いつでもあなたの変化を歓迎します。
ほとんどの開発者は、2番目のフォームを一目で理解できます。私の意見では、1番目の形式のように単純化することは単に不要です。
次のようにスペースと中括弧を追加すると、読みやすさが向上します。
obj.NeedsChange = obj.Performance <= LOW_PERFORMANCE;
または
obj.NeedsChange = ( obj.Performance <= LOW_PERFORMANCE );
jacob Raihleが述べたように。