C# での var キーワードの使用

Question

C# 3 での 'var' キーワードの使用について同僚と議論した後、var による型推論の適切な使用法について人々の意見はどうなっているのだろうかと疑問に思いました。

たとえば、私は疑わしい状況で var をかなり怠惰に使用していました。例:-

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

var のより正当な使用法は次のとおりです。

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

興味深いことに、LINQ は少しグレーゾーンのようです。例:-

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

IEnumerable を実装する型であるため、結果がどうなるかは明らかですが、新しいオブジェクトを宣言する var と同様に、完全に明らかではありません。

オブジェクトへの LINQ となると、さらに状況は悪化します。例:-

var results = from item in someList
              where item != 3
              select item;

これは同等の foreach(var item in someList) { // ...} と同等です。

ここでは型の安全性について大きな懸念があります。たとえば、IEnumerable<int> と IEnumerable<double> を受け入れるオーバーロードされたメソッドにクエリの結果を配置すると、呼び出し元が誤って間違った型を渡してしまう可能性があります。

var する 強い型付けを維持する必要がありますが、問題は、その型が定義上ですぐに明らかでないことが本当に危険なのかということです。オーバーロードによって、意図せずに間違った型をメソッドに渡してもコンパイラ エラーが発行されない可能性があるため、その問題はさらに大きくなります。

Answer 1

私はまだ思っています var 場合によってはコードを読みやすくすることができます。Orders プロパティを持つ Customer クラスがあり、それを変数に割り当てたい場合は、次のようにします。

var orders = cust.Orders;

Customer.Orders がどうかは気にしません。 IEnumerable<Order>, ObservableCollection<Order> または BindingList<Order> - 私が望むのは、そのリストをメモリ内に保持して、後でそれを反復処理したり、カウントなどを取得したりすることだけです。

上記の宣言を次と比較してください。

ObservableCollection<Order> orders = cust.Orders;

私にとって、型名は単なるノイズです。そして、戻って Customer.Orders のタイプを変更することにした場合 (たとえば、 ObservableCollection<Order> に IList<Order>) 次に、その宣言も変更する必要があります。最初から var を使用していれば変更する必要はありません。

Answer 2

私が使う var 広範囲に。これによりコードの可読性が低下するという批判がありましたが、その主張を裏付ける議論はありませんでした。

確かに、それは私たちがどのタイプを扱っているのかが明確ではないことを意味するかもしれません。だから何？実際、これが分離設計のポイントです。インターフェイスを扱うときは、次の点を重視します。 ない 変数の型に興味があります。 var これは確かにさらに踏み込んだ解釈ですが、読みやすさの観点からは議論は変わらないと思います。プログラマは実際には変数の型に興味があるのではなく、変数が何であるかに興味を持つべきです。 する. 。これが、Microsoft が型推論を「ダック タイピング」と呼ぶ理由です。

それでは、変数を次のように宣言すると、その変数はどうなりますか? var?簡単です。IntelliSense が指示したことはすべて実行します。IDE を無視した C# に関する推論は現実から外れています。実際には、すべての C# コードは IntelliSense をサポートする IDE でプログラムされます。

私が使用している場合 var 宣言された変数を使用して、その変数が何のためにあるのか混乱してしまうと、コードに根本的に何かが間違っています。 var それは原因ではなく、症状が目に見えるようになっているだけです。メッセンジャーを責めないでください。

現在、C# チームは次のことを記載したコーディング ガイドラインをリリースしました。 var すべき のみ 匿名型を作成する LINQ ステートメントの結果をキャプチャするために使用されます (ここでは、実際の代替手段がないため) var）。まあ、それはだめです。C# チームがこのガイドラインについて適切な議論を提供しない限り、私の専門的および個人的な意見では、これはまったくのバカバカしいものであるため、私はこれを無視するつもりです。（ごめん;問題のガイドラインへのリンクはありません。）

実は（表面的には）いくつかあります。 良い説明 なぜ使用してはいけないのかについて var しかし、私は依然としてそれらは大部分が間違っていると信じています。「検索可能性」の例を見てみましょう。著者はこう主張している var 場所を探すのが難しくなります MyType 使用されている。右。インターフェースも同様です。実際、クラスがどこで使用されているかを知りたいのはなぜでしょうか?私はそれがどこでインスタンス化されるかにもっと興味があるかもしれません、そして、どこかでそのコンストラクターを呼び出す必要があるため、これはまだ検索可能です（これが間接的に行われる場合でも、型名はどこかで言及されている必要があります）。

Answer 3

私の意見では、C# における Var は 良いこと^TM. 。このように型指定された変数は依然として厳密に型指定されていますが、その型は定義されている代入の右側から取得されます。型情報は右側にあるため、ほとんどの場合、左側にも入力する必要はなく、冗長になります。これにより、タイプの安全性を損なうことなく可読性が大幅に向上すると思います。

私の観点からは、変数とメソッドに適切な命名規則を使用することは、明示的な型情報よりも読みやすさの観点から重要です。型情報が必要な場合は、いつでも (VS で) 変数の上にカーソルを置くと、それを取得できます。ただし、一般に、読者にとって明示的な型情報は必要ありません。開発者にとって、変数がどのように宣言されているかに関係なく、VS では引き続き Intellisense を利用できます。そうは言っても、型を明示的に宣言することが意味がある場合はまだあるかもしれません。おそらく、型を返すメソッドがあるかもしれません。 List<T>, 、しかし、それを次のように扱いたいとします。 IEnumerable<T> あなたの方法で。インターフェイスを使用していることを確認するには、インターフェイス タイプの変数を宣言することで、これを明示的に行うことができます。あるいは、変数は何らかの条件に基づいてすぐに値を取得するため、初期値なしで変数を宣言したい場合もあります。その場合は型が必要になります。型情報が役立つ場合、または必要な場合は、そのまま使用してください。ただし、通常はこれは必要なく、ほとんどの場合、コードを使用しない方がコードが読みやすいと思います。

Answer 4

どちらも絶対に真実ではありません。 var 読みやすさにプラスの影響もマイナスの影響も与える可能性があります。私の意見では、 var 次のいずれかに該当する場合に使用する必要があります。

1. タイプは匿名です (まあ、ここでは選択の余地はありません。 しなければならない この場合は var になります）
2. 型は、割り当てられた式に基づいて明らかです (つまり、 var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var これは糖衣構文であるため、パフォーマンスには影響しません。コンパイラーは、IL にコンパイルされると、型を推論して定義します。何もありません 実は それについてはダイナミックです。

Answer 5

C# チームのシニア ソフトウェア デザイン エンジニアである Eric Lippert は次のように述べています。

なぜそうなったのか var キーワードが導入されましたか？

2つの理由があります。1つは今日存在するもの、もう1つは3.0で発生するものです。

最初の理由は、このコードがすべての冗長性のために信じられないほど醜いことです。

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

そして、それは簡単な例です - 私は悪いことを書きました。まったく同じものを2回タイプすることを余儀なくされるときはいつでも、それは私たちが削除できる冗長性です。書くほうがずっといいよ

var mylists = new Dictionary<string,List<int>>();

コンパイラに、割り当てに基づいてタイプが何であるかを把握させます。

第二に、C＃3.0は匿名タイプを導入します。定義上の匿名タイプには名前がないので、あなたは 必要 そのタイプが匿名である場合、初期化式から変数のタイプを推測できるようにします。

私のものを強調してください。記事全体、 正直なところ、C# 3.0 は依然として静的型付けです。, 、そしてそれに続く シリーズ かなり良いです。

これは何 var のためのものです。他の用途ではおそらくうまく機能しないでしょう。JScript、VBScript、または動的型付けと比較するのは全くの間違いです。もう一度注意してください、 var は 必須 他の特定の機能を .NET で動作させるため。

Answer 6

var の使用は、賢明に選択された変数名と組み合わせる必要があると思います。

次のようにならない限り、 foreach ステートメントで var を使用しても問題ありません。

foreach (var c in list) { ... }

もっとこうだったら:

foreach (var customer in list) { ... }

...そうすれば、コードを読んだ人は「リスト」が何であるかを理解する可能性が高くなります。リスト変数自体の名前を制御できる場合は、さらに良いでしょう。

他の状況にも同じことが当てはまります。これはかなり役に立たない:

var x = SaveFoo(foo);

...しかし、これは理にかなっています:

var saveSucceeded = SaveFoo(foo);

それぞれが自分のものだと思います。私は自分自身がこれをやっていることに気づきましたが、これはまったく正気の沙汰ではありません。

var f = (float)3;

何らかの 12 ステップ var プログラムが必要です。私の名前はマットです。var を (絶対に) 使用します。

Answer 7

私たちは、新規開発の数倍の時間をメンテナンス モードに費やすことを前提として、「機械ではなく人間のためのコードを作成する」という理念を採用しました。

私にとって、コンパイラーは変数の型を「知っている」という議論は除外されます。確かに、コンパイラーはコードのコンパイルを停止するため、最初は無効なコードを書くことはできませんが、次の開発者がコードを読み取るときには無効なコードを書くことはできません。 6 か月以内に、変数の動作が正しく、または間違っているかを推測し、問題の原因を迅速に特定できるようにする必要があります。

したがって、

var something = SomeMethod();

はコーディング標準で禁止されていますが、可読性が高まるため、チーム内では次のことが推奨されています。

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

Answer 8

それは悪いことではなく、むしろスタイルの問題であり、主観的になりがちです。var を使用する場合と使用しない場合では、不整合が生じる可能性があります。

もう 1 つの懸念すべきケースとして、次の呼び出しでは、コードを見ただけでは返される型がわかりません。 CallMe:

var variable = CallMe();

それがvarに対する私の主な不満だ。

メソッドで匿名デリゲートを宣言するときに var を使用しますが、どういうわけか var は使用する場合よりもきれいに見えます Func. 。次のコードを考えてみましょう。

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

編集:Julian の入力に基づいて最後のコード サンプルを更新しました

Answer 9

Var は Variant とはまったく異なります。変数は依然として厳密に型指定されていますが、そのようにするためにキーを押さないだけです。Visual Studio でカーソルを合わせると、種類が表示されます。印刷されたコードを読んでいる場合、その型が何であるかを理解するために少し考える必要があるかもしれません。ただし、それを宣言する行は 1 行だけで、それを使用する行は多数あるため、コードを理解しやすくするには適切な名前を付けることが依然として最善の方法です。

Intellisense の使用は怠惰ですか?名前全体よりも入力する量が少なくなります。それとも、それほど仕事ではないが批判に値しないものはありますか？あると思いますが、var もその 1 つです。

Answer 10

これが必要になる可能性が最も高いのは、匿名型 (100% 必要な場合) の場合です。しかし、それはまた、些細なケースの繰り返しを避け、IMO は境界線をより明確にします。単純な初期化では型を 2 回確認する必要はありません。

例えば：

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(上記の hscroll は編集しないでください。これは要点を証明しています!!!)

対:

var data = new Dictionary<string, List<SomeComplexType<int>>>();

ただし、これが誤解を招く場合があり、潜在的にバグを引き起こす可能性があります。使用には注意してください var 元の変数と初期化された型が同一でない場合。例えば：

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

Answer 11

var が難しい具体的なケースを 1 つ挙げます。オフラインのコードレビュー、特に紙の上で行われるコードレビュー。

マウスオーバーに頼ることはできません。

Answer 12

何が大したことなのか分かりません。

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

「何か」についてはまだ完全なインテリセンスがあり、曖昧なケースに対しては単体テストがありますよね?（ あなたは？)

これは varchar ではなく、dim ではなく、もちろん動的または弱い型付けでもありません。次のような Maddnes を停止しています。

List<somethinglongtypename> v = new List<somethinglongtypename>();

そして、その全体的な頭の中の混乱を次のように軽減します。

var v = new List<somethinglongtypename>();

素晴らしいですが、次のような素晴らしいものではありません:

v = List<somethinglongtypename>();

でもそれでは ブー のためのものです。

Answer 13

誰かが使用している場合、 var 彼らは「タイプを把握」したくないからキーワードを使用しますが、それは間違いなく間違った理由です。の var キーワードは動的型の変数を作成しません。コンパイラーは依然として型を認識する必要があります。変数には常に特定の型があるため、可能であればその型もコード内で明示する必要があります。

を使用する十分な理由 var キーワードはたとえば次のとおりです。

• 必要な場所、つまり匿名型の参照を宣言します。
• コードが読みやすくなる場合、つまり繰り返しの宣言を削除します。

データ型を書き出すと、多くの場合、コードが理解しやすくなります。使用しているデータ型が表示されるので、最初にコードの動作を理解してデータ型を理解する必要はありません。

Answer 14

現在の Intellisense の強力さを考えると、クラス内のメンバー変数や、目に見える画面領域外で定義されているメソッド内のローカル変数よりも var が読みにくいかどうかはわかりません。

次のようなコード行がある場合、

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

は、以下に比べてはるかに読みやすい、または読みにくいです。

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

Answer 15

VAR で重要なことは、適切な場合にのみ VAR を使用することだと思います。Linq で何かを行うとき (おそらく他の場合も)、それが容易になります。

もしそうなら 得た 何かの型を指定した場合は、それを使用する必要があります。そうしないのは単純な怠惰です（一般的に推奨される創造的な怠惰とは対照的です。優秀なプログラマは、怠惰になるために非常に一生懸命働くことが多く、それが怠惰の原因であると考えられます）そもそも）。

全面的な禁止はそもそも構造を悪用するのと同じくらい悪いですが、賢明なコーディング標準が必要です。

もう 1 つ覚えておくべきことは、型を変更できないという点で、VB の型変数ではないということです。 は 厳密に型指定された変数は、その型が推論されているだけです (そのため、これを foreach などで使用するのは不合理ではないと主張する人もいますが、読みやすさと保守性の両方の理由から、私は反対します)。

これは走り続けるのではないかと思います (-:

マーフ

Answer 16

もちろん、 int 簡単ですが、変数の型が IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var を使用すると作業がはるかに簡単になります。

Answer 17

から盗まれた この問題については、CodingHorror に投稿してください:

---

残念ながら、あなたも他の人もかなり間違っています。冗長性が良いことではないという意見には私も同意しますが、この問題を解決するより良い方法は次のようなことをすることでした。

MyObject m = new();

または、パラメーターを渡す場合:

人物 p = new("名", "姓);

新しいオブジェクトの作成時に、コンパイラーは右側ではなく左側から型を推測します。これには、フィールド宣言でも使用できるという点で、「var」よりも優れた利点があります (他にも同様に役立つ分野がいくつかありますが、ここでは触れません)。

結局のところ、それは冗長性を減らすことを目的としたものではありませんでした。誤解しないでください。「var」は、C# では匿名型/プロジェクションにとって非常に重要ですが、ここでの使用は、型を難読化するため、まったく外れています (そして私はこれを長い間言い続けてきました)。使用されています。2 回入力する必要があるのは頻度が多すぎますが、0 回宣言するのは少なすぎます。

Nicholas Paldino .NET/C# MVP、2008 年 6 月 20 日 08:00 AM

---

入力の手間を減らすことが主な関心事であれば、これを使用しないようにする議論は何もないと思います。

するだけなら これまで 自分がコードを見る人になっても、誰が気にするでしょうか？それ以外の場合は、次のような場合です。

var people = Managers.People

それは問題ありませんが、次のような場合は次のとおりです。

var fc = Factory.Run();

私の脳がコードの「英語」から形成し始める可能性のある直接的なタイプの推論をショートさせます。

それ以外の場合は、あなたのプロジェクトに取り組む必要がある可能性のある他の人に対して、最善の判断とプログラミングの「礼儀」を持ってください。

Answer 18

使用する var 明示的な型の代わりに、リファクタリングがはるかに簡単になります (したがって、違いがない、または純粋に「構文糖」であることを意味した以前のポスターに反論しなければなりません)。

このメソッドが呼び出されるすべてのファイルを変更しなくても、メソッドの戻り値の型を変更できます。想像する

...
List<MyClass> SomeMethod() { ... }
...

これは次のように使用されます

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

リファクタリングしたい場合 SomeMethod() を返す IEnumerable<MySecondClass>, 、変数宣言を変更する必要があります (また、 foreach) メソッドを使用したすべての場所で。

書いたら

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

代わりに、変更する必要はありません。

Answer 19

@あく:その一例がコードレビューです。別の例は、シナリオのリファクタリングです。

基本的に、私はマウスを使ってタイプハンティングをしたくありません。ご利用いただけない場合もございます。

Answer 20

それは好みの問題です。こういった大騒ぎは、 タイプ 動的に型付けされた言語に慣れると、変数の存在はなくなります。あれは、 もし あなたはそれらを好きになり始めます（誰もがそうできるかどうかはわかりませんが、私はそうします）。

C# var それはかなりクールです 見た目 動的型付けと似ていますが、実際には 静的 タイピング - コンパイラは正しい使用法を強制します。

変数の型は実際にはそれほど重要ではありません (これは以前にも述べました)。コンテキスト (他の変数やメソッドとの相互作用) とその名前から比較的明らかであるはずです - 期待しないでください 顧客リスト を含む int...

私はまだ上司がこの件についてどう思うか待っています。3.5 で新しい構造を使用することについては全面的に「どうぞ」とのことですが、メンテナンスについてはどうするのでしょうか?

Answer 21

比較すると、 IEnumerable<int> そして IEnumerable<double> 心配する必要はありません。間違った型を渡してもコードはコンパイルされません。

タイプセーフについては心配ありません。 var は ない 動的。これは単なるコンパイラの魔法であり、安全でない型の呼び出しは捕捉されます。

Var Linq には絶対に必要です。

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

さあ見てください anon列挙 インテリセンスでは次のように表示されます IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

C# コンパイラは非常に賢いものです。プロパティが一致する場合、個別に生成された anon 型は同じ生成された型になります。

それ以外では、インテリセンスがある限り、使用するのは理にかなっています。 var 文脈が明確な場所ならどこでも。

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

Answer 22

それはあなたの視点次第だと思います。私自身、次のような理由でコードを理解するのに苦労したことはありません。 var 「誤用」、そして私の同僚と私はいたるところでこの言葉をよく使います。(この点で Intellisense が非常に役立つことに私は同意します。) 反復的な煩わしさを取り除く方法として、これを歓迎します。

結局のところ、次のような if ステートメントは

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

実際に対処するのが不可能であれば、動的に型付けされた言語を使用する人は誰もいないでしょう。

Answer 23

var は、使用されている型が明らかな場合にのみ使用します。

たとえば、この場合は var を使用します。これは、x が「MyClass」型であることがすぐにわかるためです。

var x = new MyClass();

このような場合は var を使用しません。MyFunction がどのような型を返すかを確認するには、コード上にマウスをドラッグしてツールチップを確認する必要があるからです。

var x = MyClass.MyFunction();

特に私は、 一度もない 右辺がメソッドではなく値のみの場合は、var を使用します。

var x = 5;

(コンパイラーは、バイト、ショート、整数、またはその他が必要かどうかを知ることができないため)

Answer 24

私にとっての反感は、 var は、.NET におけるバイリンガリズムが重要である理由を示しています。VB .NET も使用したことのある C# プログラマーにとって、VB .NET の利点は次のとおりです。 var は直感的に明らかです。標準の C# 宣言は次のとおりです。

List<string> whatever = new List<string>();

VB .NET では、次のように入力するのと同じです。

Dim whatever As List(Of String) = New List(Of String)

ただし、VB .NET では誰もそれを行いません。.NET の最初のバージョンからこれができたのですから、そんなことをするのは愚かなことでしょう...

Dim whatever As New List(Of String)

...これにより、変数が作成され、それがすべて 1 つの適度にコンパクトな行で初期化されます。ああ、でも、もし欲しい場合はどうしますか？ IList<string>, ではありません List<string>?VB .NET では、これを行う必要があることを意味します。

Dim whatever As IList(Of String) = New List(Of String)

C# で行う必要があるのと同じように、明らかに使用できません var のために：

IList<string> whatever = new List<string>();

もし、あんたが 必要 タイプは違うものになる可能性があります。しかし、優れたプログラミングの基本原則の 1 つは冗長性を減らすことであり、var はまさにそれを行います。

Answer 25

匿名型に使用してください。それがその目的です。それ以外のものは使いすぎです。C で育った多くの人と同様、私も型の宣言の左側を見ることに慣れています。必要がない限り右側を見ません。使用する var というのも、古い宣言をするといつもそうすることになり、個人的には不快に感じるからです。

「そんなの関係ない、自分が満足するものを使え」と言っている人は全体像を見ていません。誰もが一度は他の人のコードを手に取り、それを書いた時点で下した決定に対処しなければなりません。全体の ' を追加せずに、根本的に異なる命名規則、または古典的な不満の括弧スタイルに対処しなければならないのは十分に悪いことです。var かどうか』をミックスに加えてください。最悪のケースは、1 人のプログラマーが使用しなかった場合です。 var そして、それを愛するメンテナが現れ、それを使用してコードを拡張します。これで、とんでもない混乱が生じました。

標準は、ランダムなコードを見つけてすぐに理解できる可能性がはるかに高いことを意味するため、まさに良いことです。違うものが多ければ多いほど、それは難しくなります。そして、「どこでも var」スタイルに移行すると、 大きい 違い。

私は動的型付けも気にしませんし、暗黙的型付けも、それらのために設計された言語で気にしません。私はPythonがとても好きです。しかし、C# は静的に明示的に型指定される言語として設計されており、それがそのまま残されるべきです。匿名型のルールを破ることは十分に悪いことでした。それをさらに進めて、言語の慣用句をさらに壊すことを人々に許可することは、私にとって満足ではありません。魔神がボトルから出てしまったので、もう元に戻ることはありません。C# は複数のグループに分けられるようになるでしょう。良くない。

Answer 26

テスト中に、次のようなコードがあることに気づくことがよくあります。

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

さて、時々、SomeOtherThing 自体に何が含まれているかを確認したいことがありますが、SomeOtherThing は CallMethod() が返す型と同じではありません。ただし、var を使用しているので、これを変更するだけです。

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

これに：

var something = myObject.SomeProperty.SomeOtherThing;

var がなければ、左側で宣言された型も変更し続ける必要があります。細かいことだとは思いますが、非常に便利です。

Answer 27

と思っている愛好家の方へ var 時間を節約し、入力するキーストロークが少なくなります。

StringBuilder sb = new StringBuilder();

よりも

var sb = new StringBuilder();

信じられないなら数えてください...

19 対 21

必要に応じて説明しますが、試してみてください...(インテリセンスの現在の状態によっては、それぞれについてさらにいくつか入力する必要がある場合があります)

そしてそれはあなたが考えられるすべてのタイプに当てはまります!!

私の個人的な感覚では、var はコードの認識可読性を低下させるため、型が不明な場合以外は決して使用すべきではありません。脳がタイプを認識するには、実線よりも時間がかかります。マシンコードとビットを理解している古いタイマーは、私が何について話しているのかを正確に理解しています。脳は並列処理を行うため、var を使用すると入力を強制的にシリアル化することになります。なぜ脳をもっと働かせたいと思うのでしょうか?それがコンピュータの目的です。

Answer 28

私は var をあらゆる場所に分割していますが、私にとって唯一疑わしい場所は内部の short 型です。私は好きです int i = 3; 以上 var i = 3;

Answer 29

昨日書いたコードからすると、確かに物事は簡単になります。

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

これがなければ非常に冗長になってしまうでしょう var.

補遺:言語を使って過ごす少しの時間 本物 型推論 (例:F#) は、式の型を正しく取得する点でコンパイラがいかに優れているかを示します。それは確かに私が使用する傾向があることを意味しました var できる限り、明示的な型を使用すると、変数が初期化式の型ではないことが示されます。

Answer 30

型名を 2 回書く必要がないことを除いて、何もありません。 http://msdn.microsoft.com/en-us/library/bb383973.aspx