簡潔さがもはや美徳ではなくなったのはどの時点ですか？

最近のバグ修正では、他のチームメンバーによって記述されたコードを調べる必要がありましたが、そこで見つけました（C＃です）。

return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0;

さて、これらすべてのキャストに正当な理由があるので、これを理解するのは非常に難しいようです。計算に小さなバグがあり、問題を解決するためにそれを解く必要がありました。

私はこの人のコーディングスタイルをコードレビューから知っていますが、彼のアプローチは、短い方が常に良いということです。そしてもちろん、そこには価値があります。私たちはすべて、適切に配置されたいくつかの演算子で整理できる条件ロジックの不必要に複雑なチェーンを見てきました。しかし、彼は明らかに、私よりも単一のステートメントに詰め込まれた一連の演算子に精通しています。

もちろん、これは最終的にはスタイルの問題です。しかし、コードを簡潔にするための努力が役に立たなくなり、理解の障壁となる点を認識することに関して何か書いたり、研究したりしましたか？

_{キャストの理由はEntity Frameworkです。データベースはこれらをnull許容型として保存する必要があります。小数？C＃のDecimalとは異なり、キャストする必要があります。}

現在の研究に関する質問に答えるために

しかし、コードを簡潔にするための努力が役に立たなくなり、理解の障壁となる点を認識することに関して何か書いたり、研究したりしましたか？

はい、この分野で作業が行われています。

このようなものを理解するには、メトリックを計算する方法を見つけて、定量的に比較できるようにする必要があります（他の回答のように、ウィットと直感に基づいて比較を実行するだけではありません）。検討されている潜在的な指標の1つは

循環的複雑度 ÷コードのソース行（SLOC）

コード例では、すべてが1行に圧縮されているため、この比率は非常に高くなっています。

SATCは、最も効果的な評価はサイズと[サイクロマティック]複雑さの組み合わせであると判断しました。複雑度が高く、サイズが大きいモジュールは、信頼性が最も低くなる傾向があります。また、サイズが小さく複雑なモジュールは、非常に簡潔なコードになる傾向があり、変更や修正が難しいため、信頼性のリスクです。

リンク

興味のある方のための参考文献をいくつか紹介します。

McCabe、T. and A. Watson（1994）、Software Complexity（CrossTalk：The Journal of Defense Software Engineering）。

ワトソン、AH、およびマッケイブ、TJ（1996）。構造化テスト：循環的複雑度メトリックを使用したテスト方法（NIST Special Publication 500-235）。2011年5月14日、McCabe Software Webサイトから取得：http : //www.mccabe.com/pdf/mccabe-nist235r.pdf

Rosenberg、L.、Hammer、T.、Shaw、J.（1998）。ソフトウェアメトリックと信頼性（ソフトウェア信頼性工学に関するIEEE国際シンポジウムの議事録）。2011年5月14日、ペンシルベニア州立大学のWebサイトから取得：http : //citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.104.4041&rep=rep1&type=pdf

私の意見と解決策

個人的には、簡潔さを重視したことはなく、読みやすさだけを重視しました。簡潔さが読みやすさを助ける場合もあれば、そうでない場合もあります。さらに重要なことは、書き込み専用コード（WOC）の代わりにReally Obvious Code（ROC）を書いていることです。

ただの楽しみのために、ここに私がそれを書く方法を示し、私のチームのメンバーにそれを書くように頼みます：

if ((costIn <= 0) || (costOut <= 0)) return 0;
decimal changeAmount = costOut - costIn;
decimal changePercent = changeAmount / costOut * 100;
return changePercent;

また、作業変数を導入すると、整数演算の代わりに固定小数点演算がトリガーされるという嬉しい副作用があるため、これらすべてのキャストの必要性decimalがなくなります。

簡潔さは重要なことの周りの乱雑さを軽減するのに適していますが、簡潔になり、関連するデータの密度が高すぎて簡単に追跡できない場合、関連するデータ自体が乱雑になり、問題が発生します。

この特定のケースでは、キャストdecimalが何度も繰り返されています。おそらく全体的に次のように書き直す方が良いでしょう：

var decIn = (decimal)CostIn;
var decOut = (decimal)CostOut;
return decIn > 0 && CostOut > 0 ? (decOut - decIn ) / decOut * 100 : 0;
//                  ^ as in the question

突然、ロジックを含む行がはるかに短くなり、1本の水平線に収まるので、スクロールせずにすべてを見ることができ、その意味がはるかにわかりやすくなります。

私はこのテーマに関する特定の研究を引用することはできませんが、あなたのコード内のすべてのキャストが自分自身を繰り返さないという原則に違反していることをお勧めします。あなたのコードがやろうとしているのは、costInand costOutをtype Decimalに変換し、そのような変換の結果に対していくつかの健全性チェックを実行し、チェックに合格した場合、それらの変換された値に対して追加の操作を実行することです。実際、コードは変換されていない値に対して健全性チェックの1つを実行し、costOutがゼロより大きく、Decimal表現できる最小のゼロ以外のサイズの半分未満の値を保持する可能性を高めます。コードはDecimal、変換された値を保持する型の変数を定義し、それらに基づいて動作する場合、はるかに明確になります。

それはあなたがの割合で、より興味があるという好奇心に見えるんDecimalの表現costInとcostOutの実際の値の比率よりcostInとcostOut、コードはまた、いくつかの他の目的のために、小数点の表現を使用する予定されていない限り。コードがこれらの表現をさらに使用する場合、それは、コード全体で連続したキャストのシーケンスを持つのではなく、それらの表現を保持する変数を作成するためのさらなる引数になります。

そのコードを見て、「コストを0（またはそれ以下）にするにはどうすればよいですか？」それはどのような特別なケースを示していますか？コードは

bool BothCostsAreValidProducts = (CostIn > 0) && (CostOut > 0);
if (!BothCostsAreValidProducts)
  return NO_PROFIT;
else {
   // that calculation here...
}

私はここで名前について推測しています：変更BothCostsAreValidProductsしNO_PROFIT、必要に応じて。

簡潔さは、それ自体が美徳ではなく目的を意味することを忘れると、美徳になるのをやめます。簡潔さと相関しているため、簡潔さが好きです。また、単純なコードは理解しやすく、修正しやすく、バグが少ないため、単純さが好きです。最後に、これらの目標を達成するためのコードが必要です。

1. 最小限の作業でビジネス要件を満たします

2. バグを避ける

3. 将来的に変更を加えて、1および2を満たすようにします。

これらが目標です。設計の原則または方法（KISS、YAGNI、TDD、SOLID、証明、型システム、動的メタプログラミングなど）は、これらの目標を達成するのに役立つ範囲でのみ有益です。

問題の行は、最終目標を見失っているようです。短いですが、単純ではありません。実際には、同じキャスト操作を複数回繰り返すことにより、不必要な冗長性が含まれています。コードを繰り返すと、複雑さが増し、バグが発生する可能性が高くなります。キャストと実際の計算を混合すると、コードを追跡しにくくなります。

ラインには3つの懸念事項があります：ガード（特別なケーシング0）、型キャスト、計算 それぞれの懸念は単独で取られた場合は非常に単純ですが、すべてが同じ表現に混在しているため、追跡するのが難しくなります。

なぜCostOut初めて使用されるときにキャストされないのかは明らかではありませんCostIn。正当な理由があるかもしれませんが、意図は明確ではありません（少なくともコンテキストがないわけではありません）。そして、これは保守性への嫌悪感です。

CostIn0と比較する前にキャストされるため、浮動小数点値であると想定します。（intの場合、キャストする理由はありません）。しかしCostOut、floatの場合、浮動小数点値は小さいがゼロではないかもしれませんが、10進数にキャストするとゼロになるため、コードは不明瞭なゼロ除算バグを隠す可能性があります（少なくともこれは可能だと思います）。

そのため、問題は簡潔さや不足ではなく、保守が困難なコードにつながる懸念事項の論理と混同が繰り返されることです。

キャストされた値を保持する変数を導入すると、おそらく、トーク数でカウントされるコードのサイズが大きくなりますが、複雑さを減らし、懸念を分離し、明快さを改善します。これにより、理解しやすく保守しやすいコードの目標に近づくことができます。

簡潔さは美徳ではありません。読みやすさが美徳です。

簡潔さは、美徳を達成するためのツールになる可能性があります。また、あなたの例のように、正反対の何かを達成するためのツールになる可能性もあります。この方法でも、別の方法でも、独自の価値はほとんどありません。コードを「できるだけ短く」するというルールは、「できるだけわいせつなもの」に置き換えることもできます。これらはすべて意味がなく、より大きな目的に役立たない場合は損害を与える可能性があります。

その上、あなたが投稿したコードは簡潔さの規則さえも守っていません。定数がMサフィックスで宣言されていた場合(decimal)、コンパイラが残りintをにプロモートするため、恐ろしいキャストのほとんどを回避できましたdecimal。あなたが説明している人は、簡潔さを言い訳に使っているだけだと思います。ほとんどの場合、故意ではありませんが、それでもです。

私の長年の経験では、究極の簡潔さは時間のそれであると信じるようになりました -時間は他のすべてを支配します。これには、パフォーマンスの時間（プログラムがジョブを実行するのにかかる時間）とメンテナンスの時間（機能を追加したりバグを修正するのにかかった時間）の両方が含まれます。（これら2つのバランスをどのように取るかは、問題のコードが実行される頻度と改善の度合いに依存します- 早すぎる最適化は依然としてすべての悪の根源であることを忘れないでください。）短いコードは通常より高速に実行され、通常は理解しやすく、したがって保守が簡単です。どちらも実行しない場合、それは正味のマイナスです。

ここに示されているケースでは、読みやすさを犠牲にして、テキストの簡潔さが行数の簡潔と誤解されていると思います。（キャストの実行方法にもよりますが、実行に時間がかかる場合がありますが、上記の行が数百万回実行されない限り、おそらく問題ではありません。）最も重要な計算が何であるかを参照してください。私は次のように書いたでしょう：

decimal dIn = (decimal)CostIn;
decimal dOut = (decimal)CostOut;
return dIn > 0 && CostOut > 0 ? ((dOut - dIn) / dOut) * 100 : 0;

（編集：これは他の回答と同じコードなので、そこに行きます。）

私は三項演算子のファンな? :ので、そのままにしておきます。

読みやすさの上のほぼすべての答えと同様に、常にあなたの主な目標でなければなりません。ただし、変数や新しい行を作成するよりも、書式設定の方がより効果的な方法になると考えています。

return ((decimal)CostIn > 0 && CostOut > 0) ?
       100 * ( (decimal)CostOut - (decimal)CostIn ) / (decimal)CostOut:
       0;

ほとんどの場合、循環的複雑性の議論に強く同意しますが、あなたの関数は小さくてシンプルで、良いテストケースでよりよく対処できるように見えます。好奇心から、なぜ小数にキャストする必要があるのですか？

私には、ここでの読みやすさの大きな問題は、フォーマットの完全な欠如にあるように見えます。

次のように書きます。

return (decimal)CostIn > 0 && CostOut > 0 
            ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 
            : 0;

CostInand の型がCostOut浮動小数点型か整数型かによって、キャストの一部も不要になる場合があります。floatおよびとは異なりdouble、整数値は暗黙的にに昇格されdecimalます。

コードは急いで書くことができますが、私の世界では上記のコードはもっと良い変数名で書かれるべきです。

そして、コードを正しく読んだ場合、粗利益の計算を試みています。

var totalSales = CostOut;
var totalCost = CostIn;
var profit = (decimal)(CostOut - CostIn);
var grossMargin = 0m; //profit expressed as percentage of totalSales

if(profit > 0)
{
    grossMargin = profit/totalSales*100
}

私は整数でコスティン* CostOutを想定しています
。これは、私はそれを書くだろうかである
10進数ですM（マネー）

return CostIn > 0 && CostOut > 0 ? 100M * (CostOut - CostIn) / CostOut : 0M;

コードは、人々が理解できるように書かれています。この場合の簡潔さはあまり買わず、メンテナーの負担を増やします。この簡潔さのために、コードをより自己文書化する（変数名を改善する）か、このように機能する理由を説明するコメントを追加することにより、絶対に拡張する必要があります。

今日問題を解決するコードを書くとき、そのコードは明日、要件が変わるときに問題になる可能性があります。メンテナンスを常に考慮する必要があり、コードの理解度を向上させることが不可欠です。

簡潔さはもはや美徳ではありません

• ゼロの事前チェックなしの部門があります。
• nullのチェックはありません。
• クリーンアップはありません。
• TRY CATCH vsエラーを処理できるフードチェーンをスローします。
• 非同期タスクの完了順序について想定されています
• 将来のスケジュール変更の代わりに遅延を使用するタスク
• 不要なIOが使用されています
• 楽観的更新を使用しない

これが検証ユニットテストに合格している場合、新しい仕様が追加され、新しいテストまたは拡張された実装が必要であり、コードの簡潔さを「解く」必要がある場合は問題ありません。問題が発生します。

明らかにコードのバグは、Q / Aに別の問題があることを示していますが、これは見落としでした。したがって、キャッチされなかったバグがあったという事実は懸念の原因です。

コードの「読みやすさ」などの非機能要件を処理する場合、開発マネージャーが定義し、リード開発者が管理し、開発者が適切な実装を保証するように尊重する必要があります。

「読みやすさ」と「保守性」の容易さを確保するために、コードの標準化された実装（標準と規則）を確保するようにしてください。ただし、これらの品質属性が定義および適用されていない場合、上記の例のようなコードになります。

この種のコードを見たくない場合は、実装の標準と規則についてチームに同意してもらい、書き留めて、規則が尊重されていることを検証するためにランダムなコードレビューまたはスポットチェックを行ってください。