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

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 は強い型付けを維持しますが、問題は、型が定義上すぐに明らかにならないことが危険であるかどうかです。オーバーロードは、誤った型をメソッドに誤って渡したときにコンパイラエラーが発行されないことを意味する場合に拡大されます。

私はまだ考えて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を使用した場合は、行う必要はありません場所。

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

確かに、それは私たちが扱っているタイプが明確でないことを意味するかもしれません。だから何？これは、実際には分離された設計のポイントです。インターフェースを扱う場合、変数の型には特に関心がありません。var真、さらにこのくらいかかりますが、私は、引数は、ビューの読みやすさの点から、同じままであることを考える：プログラマは、実際に変数の型ではなく、変数が何に興味があるべきではないん。これが、マイクロソフトが型推論を「ダックタイピング」とも呼ぶ理由です。

では、変数を使用して宣言するとvarどうなりますか？簡単です。IntelliSenseが教えてくれることは何でも実行します。IDEを無視するC＃についての推論は、現実には不十分です。実際には、すべてのC＃コードは、IntelliSenseをサポートするIDEでプログラムされています。

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

現在、C＃チームは、匿名型を作成するLINQステートメントの結果をキャプチャするためにのみ使用するvar必要があることを明記したコーディングガイドラインをリリースしました（ここでは、var）。まあ、それをねじ込みます。C＃チームがこのガイドラインに適切な議論を示さない限り、私はそれを無視します。私の専門家および個人的な意見では、それは純粋な愚か者だからです。（申し訳ありません。問題のガイドラインへのリンクはありません。）

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

Varは、私の意見では、C＃では^tmは良いことです。そのように型付けされた変数は、引き続き強く型付けされますが、定義されている代入の右側から型を取得します。タイプ情報は右側にあるため、ほとんどの場合、左側にも入力する必要はなく、過度に冗長です。これにより、型の安全性を低下させることなく、読みやすさが大幅に向上すると思います。

私の観点からは、変数とメソッドに適切な命名規則を使用することは、明示的な型情報よりも可読性の観点から重要です。タイプ情報が必要な場合は、いつでも（VSの）変数にカーソルを合わせて取得できます。ただし、一般的には、明示的な型情報は読者には必要ありません。開発者にとって、VSでは、変数の宣言方法に関係なく、Intellisenseを引き続き使用できます。以上をすべて説明した後でも、型を明示的に宣言することが理にかなっている場合はまだあるかもしれません-おそらく、List<T>、それをIEnumerable<T>あなたの方法で。インターフェイスを確実に使用するために、インターフェイスタイプの変数を宣言することで、これを明示的にすることができます。または、おそらく、初期値なしで変数を宣言する必要があります-ある条件に基づいて値をすぐに取得するためです。その場合はタイプが必要です。タイプ情報が有用または必要な場合は、先に進んで使用してください。しかし、私は通常、それは必要ではなく、ほとんどの場合、コードがなくてもコードを読みやすくなると感じています。

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

1. 型は匿名です（この場合、varである必要があるため、ここでは選択肢がありません）。
2. タイプは、割り当てられた式（つまりvar foo = new TypeWithAReallyLongNameTheresNoSenseRepeating()）に基づいて明らかです

var構文上の砂糖であるため、パフォーマンスへの影響はありません。コンパイラはタイプを推測し、ILにコンパイルされるとそれを定義します。それについて実際に動的なものは何もありません。

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、または動的型付けとの比較は、完全に2段になります。もう一度注意してください。.NETで他の特定の機能を動作させるには、varが必要です。

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プログラムが必要です。私の名前はマットです。

私たちは、「マシンではなく人のためのコード」という考え方を採用しました。これは、新規開発よりもメンテナンスモードで何倍も長い時間を費やすという前提に基づいています。

私にとって、それはコンパイラが変数のタイプを「知っている」という引数を除外します-確かに、コンパイラはコードのコンパイルを停止するため、最初に無効なコードを書くことはできませんが、次の開発者がコードを読んでいるとき6か月後には、変数が正しくまたは誤って行っていることを推測し、問題の原因をすばやく特定できる必要があります。

したがって、

var something = SomeMethod();

はコーディング標準で非合法ですが、読みやすさを向上させるため、次のことをチームで推奨しています。

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

それは悪くはありません、それは主観的である傾向があるより文体的なものです。varを使用する場合と使用しない場合で、矛盾が発生する可能性があります。

もう1つの懸念事項は、次の呼び出しでは、によって返されるタイプをコードを見ただけではわかりませんCallMe。

var variable = CallMe();

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

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

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

編集：ジュリアンの入力に基づいて最後のコードサンプルを更新しました

Varはバリアントとはまったく異なります。変数はまだ強く型付けされています。キーを押さずにそのまま取得するだけです。Visual Studioでこれにカーソルを合わせると、タイプを確認できます。印刷されたコードを読んでいる場合、型を理解するために少し考えなければならない可能性があります。しかし、それを宣言する1行とそれを使用する多くの行があるため、適切な名前を付けることは、コードをわかりやすくするための最良の方法です。

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

これが必要になる可能性が最も高いのは、匿名型の場合です（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);

varが難しい1つの特定のケース：オフラインのコードレビュー、特に紙で行われたもの。

そのためのマウスオーバーに依存することはできません。

大したことは何だかわかりません。

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

あなたはまだ「何か」について完全なインテリセンスを持っています、そして曖昧なケースのためにあなたはユニットテストを持っていますよね？（ あなたは？ ）

これはvarcharではなく、薄暗くなく、動的な型付けや弱い型付けではありません。次のようにマドンを停止しています：

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

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

var v = new List<somethinglongtypename>();

いいですね、それほどいいわけではありません：

v = List<somethinglongtypename>();

しかし、それがブーの目的です。

var「タイプを計算する」ことを望まないために誰かがキーワードを使用している場合、それは間違いなく間違った理由です。のvarダイナミック型の変数を作成していないキーワードが、コンパイラは、まだタイプを知っている必要があります。変数は常に特定の型を持っているので、可能であれば、型もコードで明確にする必要があります。

varキーワードを使用する正当な理由は次のとおりです。

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

データ型を書き出すと、コードがわかりやすくなります。これは、使用しているデータ型を示しているため、最初にコードが何をするかを理解することによってデータ型を理解する必要はありません。

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

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

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

Isは次の場合よりもはるかに簡単または読みにくくなっています。

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

VARの重要な点は、適切な場所でのみ使用することです。つまり、Linqでそれを容易にする（そしておそらく他の場合でも）ことを行うときです。

あなたはしている場合ですに何かのタイプあるは、それを使用する必要があります-そうしないのは単純な遅延です（一般的に推奨される創造的な遅延とは対照的です）-優れたプログラマーは、怠惰になるために非常に熱心に働き、検討することができますそもそものものの出所）。

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

覚えておくべき他の事は、それが種類を変更できないということで、そのことVBの型varがあることである-それはある強く型付けされた変数の型が（推測されるだけというこれまでその不合理ではないと主張しているだろう人がいる理由でありますたとえば、foreachで使用しますが、可読性と保守性の両方の理由で同意しません）。

これは実行されると思います（-：

マーフ

確かにint簡単ですが、変数の型がのIEnumerable<MyStupidLongNamedGenericClass<int, string>>場合、varを使用すると処理が簡単になります。

CodingHorrorのこの問題に関する投稿から盗まれた：

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

Nicholas Paldino .NET / C＃MVP（2008年6月20日08:00 AM）

私はあなたの主な関心がより少なくタイプする必要があることであると思います-それからあなたはそれを使用することからあなたを揺るがすつもりであるどんな議論もありません。

あなただけしようとしている場合は、これまであなたのコードを見た人は、心配事も？そうでなければ、このような場合：

var people = Managers.People

大丈夫ですが、このような場合：

var fc = Factory.Run();

それは私の脳がコードの「英語」から形成し始める可能性があるあらゆる即時型推論を短絡します。

それ以外の場合は、プロジェクトで作業する必要がある可能性のある他の人に対して、最善の判断とプログラミングの「礼儀」を使用してください。

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());
...

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

@aku：1つの例はコードレビューです。別の例は、シナリオのリファクタリングです。

基本的に、マウスでタイプハンティングをしたくありません。利用できない場合があります。

それは好みの問題です。変数の型に関するこの面倒なことは、動的に型付けされた言語に慣れると消えます。つまり、場合あなたが彼らのように起動する（誰もができれば、私はわからないんだけど、私がやります）。

C＃varは動的型付けのように見えるという点でかなりクールですが、実際には静的型付けです-コンパイラーは正しい使用法を強制します。

変数の型はそれほど重要ではありません（これは以前に述べられています）。期待していない- （他の変数やメソッドとの相互作用）と、その名前が文脈から比較的明確にする必要がありCUSTOMERLISTが含まれてint...

私は上司がこの問題についてどう思うかをまだ見守っています。3.5で新しい構成を使用するために、「先に進む」という毛布を手に入れましたが、メンテナンスについてはどうしますか？

あなたの比較では 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
    };

インテリセンスでanonEnumerationを見ると、次のように表示されます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＃コンパイラはかなり賢いです-別々に生成された匿名型は、それらのプロパティが一致する場合、同じ生成型になります。

それ以外では、あなたがインテリセンスを持っている限り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;

それはあなたの視点によると思います。私は個人的に、var「誤用」のためにコードの一部を理解するのに困難を感じたことはありませんでした。同僚と私は、コードをかなり頻繁に使用しています。（この点でIntellisenseは大きな助けとなることに同意します。）繰り返しの残骸を取り除く方法としてそれを歓迎します。

結局のところ、ステートメントが

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

対処するのが本当に不可能だったので、動的型付け言語を使用する人は誰もいなかったでしょう。

どのタイプが使用されているかが明らかな場合にのみ、varを使用します。

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

var x = new MyClass();

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

var x = MyClass.MyFunction();

特に、私は決して右サイドにも方法が、唯一の値ではない場合にVARを使用していません。

var x = 5;

（コンパイラが、バイト、ショート、整数などが必要かどうかを認識できないため）

私にとっては、var.NETのバイリンガリズムが重要である理由に対する反感は、VB .NETも使用したC＃プログラマにとって、その利点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の役割です。

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

「問題ではないので、満足しているものを使用してください」と言っている人は、全体像を見ていません。誰もがどこかで他の人のコードを拾い、彼らがそれを書いたときに彼らが行ったどんな決定にも対処しなければなりません。まったく違うvarものをミックスに追加せずに、根本的に異なる命名規則や-古典的な不満-筋交いのスタイルに対処しなければならないのは十分に悪いことです。最悪のケースは、1人のプログラマが使用しなかった場合でvar、それを気に入って、それを使用してコードを拡張するメンテナがやって来るでしょう。だから今、あなたは不道徳な混乱を持っています。

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

私は動的なタイピングを気にしませんし、暗黙のタイピングを気にしません-それらのために設計された言語で。私はPythonがとても好きです。しかし、C＃は静的に明示的に型付けされた言語として設計されており、それが維持されるべきです。匿名型のルールを破ることは十分に悪いことでした。人々にそれをさらに受け入れさせ、言語のイディオムをさらに破らせることは私が不満なことです。魔神がボトルからなくなったので、二度と戻らないでしょう。C＃はキャンプにバルカン化されます。良くない。

テスト中に何度も、私は自分が次のようなコードを持っていることに気づきます：

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がないと、左側の宣言された型も変更し続ける必要があります。私はそれがマイナーであることを知っていますが、それは非常に便利です。

var時間を節約できると考える愛好家にとって、入力するのに必要なキーストロークは少なくなります。

StringBuilder sb = new StringBuilder();

より

var sb = new StringBuilder();

私を信じないならemを数えて...

19対21

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

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

私の個人的な感覚では、コードでの認識の読みやすさが低下するため、タイプが不明な場合を除いて、varを使用しないでください。完全なラインよりもタイプを認識するのに脳が長くかかります。マシンのコードとビットを理解している古いタイマーは、私が何を話しているかを正確に知っています。脳は並行して処理し、varを使用すると、入力をシリアル化するように強制されます。なぜ誰もが自分の脳をより強く働かせたいのでしょうか？それがコンピュータの目的です。

varをすべての場所で分割します。私にとって問題のある場所は、内部のshort型だけです。たとえばint i = 3;、var i = 3;

昨日書いたコードから、それは確かに物事をより簡単にすることができます：

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

これがないと、非常に冗長になりvarます。

補遺：実際の型推論を備えた言語（F＃など）で少し時間をかけると、コンパイラーが式の型を正しく理解するのにどれだけ優れているかがわかります。それは確かにvar私ができる限り使用する傾向があることを意味しており、明示的な型を使用すると、変数が初期化式の型ではないことが示されます。

なし。ただし、型名を2回記述する必要はありません。http://msdn.microsoft.com/en-us/library/bb383973.aspx