これら 2 つのコードがありますが、どちらが読みやすいですか?
foreach
decimal technicalPremium = 0; foreach (Risk risk in risks) { technicalPremium = technicalPremium + risk.TechnicalPremium; } return technicalPremium;
リンク
return risks.Sum(risk => risk.TechnicalPremium);
これら 2 つのコードがありますが、どちらが読みやすいですか?
foreach
decimal technicalPremium = 0;
foreach (Risk risk in risks)
{
technicalPremium = technicalPremium + risk.TechnicalPremium;
}
return technicalPremium;
リンク
return risks.Sum(risk => risk.TechnicalPremium);
コードに取り組むチームが Linq バージョンが何をするかを知っていて、その内部の仕組みを知っていれば、コードはより読みやすくなります。
好きな方を使用しますが、メソッドで非表示にします。
return risks.SumTechnicalPremium();
ない。最初のものはより冗長で、誰もが理解できる可能性があります。2 つ目はより簡潔で、linq の知識があれば誰でも簡単に理解できます。
自分の置かれている環境に合わせて選択できると思います。
LINQを読むことができる人にとっては、LINQのものです。
コードを段階的に解釈しなければならない人のために (短い方のインテリセンス/ドキュメントを使用して.
linq を使用します。説明が必要だと思われる場合は、1 行のコメントで対応します。人々が linq に慣れるにつれて、コメントの必要性はなくなります。
LINQ コードは非常に読みやすく、自己文書化されています。
最初のオプションは、より幅広い人々にとってより読みやすいものです。2 番目のオプションには、読者が LINQ を知っているか、理解している可能性があるという点で、「参入障壁」があります。これはより簡潔であるため、視聴者がその参入障壁を超えている場合に適している可能性があります。
私はc#を知りませんが、2番目の選択肢は私にははるかにきれいに見え、それが何をするのか理解できました(わかりました、最初のバージョンとの推測とクロスチェックで)。おそらくいくつかの機能的な背景のためです。ただし、最初に4(!)の場所でtechnicalPremiumを探す必要があります。2つ目は、コードを読んでいるだけの場合は、はるかに短くて理解しやすいものです。
また
10進数technicalPremium=0;
foreach(リスクにおけるリスクリスク)technicalPremium = TechnicalPremium + Risk.TechnicalPremium;
テクニカルプレミアムを返します。
Linqがより広く採用されるようになると、2番目は簡単に理解できると言う人たちに同意します。それは確かにより簡潔です。
ただし、デバッグのしやすさに懸念があります。foreachのコードをステップスルーして、各パスで何が行われているかを正確に確認する方がはるかに簡単なようです。
「読みやすい」の意味によると思います。最初の例は、プログラムのロジックを明確に示しており、プログラミングの経験がある人なら誰でも理解できるはずです。
私には、2 番目の例の方がコンテキストに基づいてより直感的です (つまり、配列 (またはその他のコレクション型) を取得し、その配列の各要素に対して Sum という名前のメソッドを実行しています)。2 番目の例があまり明確にならない唯一の場所は、実際のラムダ式自体です。特に、ラムダの経験がないか、関数型プログラミングのバックグラウンドをすでに持っている人にとってはなおさらです。
ラムダが .NET プログラミングでより一般的になるにつれて、これはあまり問題にならなくなると思います。現状では、.NET でラムダ式を使用する方法の基本を理解するには、非常に短い学習曲線しかないと思います。
各言語には、そのようなものをコーディングするための最良の方法に関する規則があるため、その言語を定期的に使用する人々にとって最も読みやすいものは普遍的ではありません. Java または通常の C# プログラマーにとっては、最初のオプションの方が読みやすいです。LINQ や関数型プログラミングに慣れている人にとっては、2 番目の方が読みやすくなります。
「Linqを知らなければ」最初のものを好きだと言っている人を見かけます。ええ、最初のものは、C# を知らないと読めません。これは「どちらが読みやすいか」という問題ではなく、「どの言語機能を使いやすいか」という問題です。
誰もが嫌う言語/フレームワーク/ツールセットの部分についてチームと話し合うことから始め、それらを立ち入り禁止と宣言します。それ以外はすべて標準語彙の一部と見なされ、全員が流暢であることが期待されます。このリストは、コーディング標準ドキュメントの「変更可能な値の型を作成しない」および「非公開メンバーの些細なプロパティを気にしない」のすぐ隣に配置する必要があります。
Linq が「除外」リストにない限り、2 番目の例は最初の例よりもはるかに読みやすくなります。なんで?読者が解読するメカニズムを単に提示するのではなく、コードの意図を宣言するためです。
より効率的であるという点で、2番目のオプションの方が優れていると思います。ただし、何が起こっているのかはあまり明らかではありません (少なくとも私には)。
あなたの目標が、あなたの後に来るかもしれない「誰でも」にとって読みやすくすることである場合は、 foreach を使用してください。私は「より読みやすい」とは、言語の基礎を経験した人なら誰でも理解できるはずだと解釈しています。linq に不慣れで、まだ VS2005 以前を使用している人にとって、linq 構文は混乱を招くでしょう。
私はlinqを知らないので最初に言います。文書化しすぎるリスクがあるので、何が起こっているのかを簡単に説明したものを使用します。または、知らないかもしれない人のためのlinqだと言ってください。
その目的を説明するコメントを提供する場合は、Linq オプションを使用します。
Linq の知識がない場合は、最初に。開発者なら誰でも最初のものを読んで理解できます。
ここには読みやすさの問題はありません。Sum をクリックして F1 を押します。
勝利のためのLinq。
コードの最初の部分は間違いなく読みやすく、少なくとも変数 risk の名前をクラスとは異なる名前に変更すれば、さらに読みやすくなります。配列リスクの名前を変更した方が良いでしょう。
2つ目ですね、間違いなく。加算のような単純なことを行うために、このような大きなコード ブロックを用意する必要はまったくありません。また、LINQが何であるかはわかりませんが、完全に読みやすいです。