私はReSharperを使用して、コードで発生する可能性のあるエラーを見つけています。エラーではありませんがvar、宣言で変数を明示的に入力する代わりに、キーワードを使用する必要があると不平を言い続けています。個人的には、私が書いた場合、私にとっても、私のコードを読んでいる人にとっても、はるかに明確だと思います。
IList<T> someVar = new List<T>();
それ以外の
var someVar = new List<T>();
両方の方法でパフォーマンスに違いがないことを知っているので、これらのヒントを無視するか、varキーワードを使用する必要がありますか？
それは好みの問題なのか、それとも暗黙的に変数を型付けするのが良い習慣なのか？
少なくとも2つの理由があります。
まず、それはDRYの原則の問題です。繰り返してはいけません。将来、変数のタイプをList<>からStack<>またはLinkedList<>に変更することにしvarた場合は、1つの場所で変更する必要があります。そうでない場合は、2つの場所で変更する必要があります。
2つ、ジェネリック型の宣言は非常に長くなる可能性があります。Dictionary<string, Dictionary<int, List<MyObject>>>誰でも？これは単純なものには当てはまりませんList<T>が、異なるオブジェクトタイプに対して2つのコードスタイルを使用するべきではありません。
それはただのスタイルの問題です。あなたの例のように右側のタイプがすぐに明らかである場合、私は好む傾向がありvarますが、それが気に入らない場合は、varそのルールを無効にすることはまったく問題ありません。多くのプログラマーは明示的な入力を好みます。
Eric Lippertのブログ記事「暗黙の入力の使用と誤用」をチェックして、いつvar適切かについての広範な議論を行ってください。
これは主にコーディングスタイルの問題です（匿名型を除く）。個人的には、コードを書くときにvarを使用することがよくありますが、ReSharperのコードクリーンアップを使用して、終了時に明示的な型に変換し直します。これにより、コードをより迅速に作成できますが、コードを自分や他の人が読みやすいと感じるものに変換できます（すべてのコードは一度作成されますが、何度も読み取られます）。
次の「言語機会設定」（オプション、コード検査、検査の重大度にあります）をオフにして、「var」を使用するためのReSharperヒントをオフにします。
イニシャライザが明示的に型を宣言する場合は、「var」キーワードを使用します。
可能な場合は「var」キーワードを使用してください。
次のコードクリーンアップ設定で、「var」を明示的なタイプに変換するようにReSharperを構成できます。
宣言で「var」を使用する
型宣言が長すぎる（15文字以上）場合にのみvarを使用します。それ以外の場合は、明示的な宣言の方が読みやすくなります。
Resharper 8.2で無効にするには、[Resharper]>[オプション]>[コード検査]>[検査の重大度]>[言語の使用機会]に移動します。検索ボックスに「使用」という単語を入力すると、リストを絞り込むのに役立ちます。
自動プロパティと同じように、簡潔にするだけです。あなたが最も快適に感じるものに固執してください。
これは、ジュニア開発者にとって素晴らしい質問です。必ずしも質問者が後輩である必要はありませんが、後輩の開発者に情報を提示する前に明確にすることは素晴らしいことです。
その精神で、この質問を見つけた人は、読みやすさが数少ない品質属性の1つであり、確かに早い段階で習得することが最も重要なものの1つであることを常に理解する必要があります。読みやすさには、いくつかの名前を付けるために、変数の命名慣行と明示的なコードが含まれます。
varとは言うものの、読みやすさの個々のミクロの側面は、キーワードを介した暗黙の入力を使用するかどうかです。簡単な答えは多分です。例を用いた知識に基づいた回答は、たぶんまれに絞り込むかもしれません。
したがって、これを理解しやすくするために、キーワードによる暗黙的な入力を使用しない理由から始めます。var
（言語の観点）暗黙の型付けを使用しない最初の理由は、C＃の主な強みは強い型付けされた言語であるためです。Javascriptのように強く型付けされないことを長所とする素晴らしい言語はたくさんあります。言語はそれぞれ異なり、独自の長所と短所があります。C＃の場合、強く型付けされることは、C＃の最も重要な強みの1つです。
この回答は、コードがSOLIDであることを前提としています。レガシーコードベースで作業している場合、または依存性注入やリスコフの置換に完全に焦点を当てていないジュニア開発者の場合、var使用法を微調整することは、現時点で焦点を当てるべき場所ではありません。
変数に割り当てる方法はいくつかあります。これらは私が今考えているものです：
ISomething someVar = new Concrete(); // <1. Can't use var to create Interfaces.
var someVar = GetFromMethod(); // <-- 2. Taken from return type
var someVar = new MyPerson(); // <-- 3. Custom complex reference type
var someVar = new DateTime(); // <-- 4. Built-in simple Reference Type
var someVar = string.Empty; // <-- <<
var someVar = new List<T>(); // <-- 5. Built-in complex Reference Type
var someVar = new Dictionary<string, Dictionary<int, List<MyObject>>>();
var someVar = true; // <-- 6. simple Value type assignment
var someVar = 1; // <-- 7. complex Value type assignment(s)
var someVar = 1.0; // <-- <<
var someVar = 1.0d; // <-- <<
foreach (var i = 0; i <= . . .) // <-- 8. Same as 7 above, but different context.
var someVar = new {Name = "yo"}; // <-- 9. Instantiate Anonymous Type
（壊す）
1.上記の例の例1では、varキーワードを使用できない場合のみを示しています。明らかに、インターフェイスの下で具体的なインスタンス化を作成することはできません。＃5でインターフェースの使用についてさらに詳しく説明します。ここではvarを使用できません
2.例2は、誰かがあなたと同じ開発ツールを使用していて、誰もがコードを読んで時間をかけてメソッドのreturnタイプを調査したいと考えていることを前提としています。コードまたはコードレビューの読み取り速度によっては、これは重要でないか、大きな欠点になる可能性があります。ここではvarを使用しないでください
3.なぜ新しいインラインをインスタンス化するのですか？前に述べたように、これらの例は、SOLIDの原則を実践していることを前提としています。変数を宣言するこの方法は、コードの臭いを作成します。コードベースでnewキーワードを検索した場合、結果は自動生成されたコード、コンポジションルート、または以下の＃4のみになります。ここではvarを使用しないでくださいこれを行う
4. new DateTime();、およびその他のいくつかのまれな組み込みの単純な型はnew、コードベースにキーワードが表示されることがまれな場合です。例4でキーワードを使用するvarことは、それほど大きな問題ではありません。しかし、正直なところ、この状況で暗黙のうちに戦うことによって何を購入していますか？文字列についても同じ質問です。ここでvarを使用できます...しかし、なぜですか？
5.常に可能な限り特定のタイプを使用しないようにする必要があります。要するに、それは小さなインターフェースを使用することを意味します。コンシューマーを壊すことなく変更を可能な限り柔軟に保ちたいため、このルールは主に外部向けAPIに適用されます。このルールが内部コードに厳密に適用されない唯一の理由は、開発者が重大な変更を加えたい場合、追加の時間をかけてブレークフィックスをカスケードするための追加の作業を行うことができるためです。それはあまり良い言い訳ではありません。
..... 5.1したがって、最初の部分では、someVarがタイプになることに注意してくださいGeneric.List<T>。IList私が見ることができるように、タイプの変数を作成したい場合は、varキーワードを使用することはあなたが望むものではありません。これは通常、可能な限り特定のタイプが最も少ない変数を宣言するためのルールです。見てください：IListvsList 。変数の使用に余分なジャンクをすべて含めることを意図的に許可したくない場合はどうなりますList<T>か？これらの規則には理由があります。 このルールに従うことができる場合は、varキーワードを使用しないようにしてください。
..... 5.2気にしない、または提案されているようにインターフェースを使用したくないと仮定すると、これは問題ありません。これは、長さの概念にもいくらか当てはまります。コレクションのネストされたレベルがあり、宣言が長い場合、varキーワードを使用したことで誰もあなたを責めることはありません。 インターフェイスを使用していない場合は問題ありません
6.これは例7に似ていますが、数値以外の値型に適用されます。簡単な質問は、「なぜ？」です。＃4で言ったように、何を買っていますか？デフォルト値を使用していると仮定すると、とにかくタイプを指定する必要があります。なぜルールを組み合わせるのか、そしてそれは何を買うのか？もちろんですが、なぜですか？
EG：とにかく時々明示する必要があります、なぜルールを混ぜるのですか？：
bool isVarOkay, canUseVar;
char a, b, c, d, e, f;
bool isSample = true;
byte etc;
var isOtherSample = true; //<-- why?
7.多数の数値型があります。その理由のほとんどは正確さのためであり、いくつかは意味論的な目的のためです。いずれにせよ、明示的ではなく、コンパイラに必要なものを推測させるのはなぜですか。明示する時間があった場合は、数値型がその時間です。plain-olに関する限り、intvarは非常に直接的で明白であるため、varを使用する余地があるかもしれません。しかし、ポイント＃8のためにそれを保存したいと思います。varキーワードは使用しないでください
8.このコード構造は非常に多くの場所で使用されているため、ほとんど問題ないようです。しかし、もう一度：なぜ、そして何を節約しているのですか？ varとintは両方とも3文字です。もちろんですが、なぜですか？
9.匿名の返品の場合、ほとんどの場合、varキーワードを使用する必要があります。そうしないと、匿名であるという目的が損なわれます。ほとんどの匿名型はインライン化できるため、結果はすぐに有用なものに変換されるため、必ずしも変数に割り当てる必要はありません。しかし、これには避ける価値のない機会がいくつかあります。必要に応じて、匿名タイプにvarを使用します。
結論
var匿名タイプの場合、キーワードは避けられません。また、Dmitryの例のように、長い宣言を行う複数レベルのジェネリックを持つジェネリック型にも役立ちますDictionary<string, Dictionary<int, List<MyObject>>>。最後に、4、5、6、8の例でキーワードを使用しても、誰の気持ちも傷つけませんvar。しかし、何も購入していません。
varキーワードを使用すると、タイプを変更したり、DRYの原則に固執したりできるという考えは、偽の言い訳に他なりません。まれな状況でのみ、宣言の割り当て側がタイプの想定を適切に表します。