405

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

4

86 に答える 86

292

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

var orders = cust.Orders;

Customer.OrdersがIEnumerable<Order>であるObservableCollection<Order>かどうかは関係ありません。またはBindingList<Order>、リストをメモリに保持して、リストを反復処理したり、後でカウントなどを取得したりするだけです。

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

ObservableCollection<Order> orders = cust.Orders;

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

于 2008-09-03T11:53:07.377 に答える
167

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

確かに、それは私たちがどのタイプを扱っているのかが明確でないことを意味するかもしれません。だから何?これは、実際には分離された設計のポイントです。インターフェイスを扱うときは、変数の型には特に関心がありません。varこれはさらに真実ですが、読みやすさの観点からは、議論は同じままだと思います。プログラマーは、実際には変数の型に関心があるのではなく、変数の機能に関心があるはずです。これが、Microsoftが型推論を「ダックタイピング」とも呼ぶ理由です。</ p>

では、変数を使用して宣言すると、変数は何をしvarますか?簡単です。IntelliSenseが教えてくれたことは何でもできます。IDEを無視するC#についての推論は、現実には及ばない。実際には、すべてのC#コードは、IntelliSenseをサポートするIDEでプログラムされます。

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

現在、C#チームは、匿名型を作成するLINQステートメントの結果をキャプチャするためにのみvar使用する必要があることを示すコーディングガイドラインをリリースしました(ここでは、に代わる実際の方法がないため)。まあ、それをねじ込みます。C#チームがこのガイドラインについて適切な議論をしてくれない限り、私はそれを無視します。私の専門的および個人的な意見では、それは純粋なバロニーだからです。(申し訳ありませんが、問題のガイドラインへのリンクはありません。)var

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

于 2008-09-03T12:01:01.087 に答える
118

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

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

于 2010-05-19T13:50:50.237 に答える
91

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

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

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

于 2010-05-19T13:49:26.243 に答える
68

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、または動的型付けとの比較は、完全なものです。繰り返しになりますが、.NETで他の特定の機能を動作させるにvarはが必要です。

于 2008-09-18T20:22:53.030 に答える
53

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を(ab)使用します。

于 2008-09-03T11:35:13.987 に答える
40

新しい開発よりも数倍長い時間をメンテナンス モードで費やすという前提に基づいて、「機械ではなく人のためのコード」という精神を採用しました。

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

したがって、

var something = SomeMethod();

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

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}
于 2008-09-17T01:08:18.007 に答える
39

それは悪いことではなく、主観的になりがちな文体的なものです。var を使用する場合と使用しない場合に、矛盾が生じる可能性があります。

もう 1 つの懸念事項として、次の呼び出しでは、コードを見ただけでは によって返される型がわからないことがありますCallMe

var variable = CallMe();

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

メソッドで匿名デリゲートを宣言するときに var を使用しますFunc。次のコードを検討してください。

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

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

于 2010-05-19T13:48:33.517 に答える
36

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

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

于 2010-05-19T13:47:43.610 に答える
27

これが必要になる可能性が最も高いのは、匿名型 (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);
于 2009-08-19T07:17:12.507 に答える
17

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

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

于 2008-09-03T11:51:16.537 に答える
17

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

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

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

于 2008-09-03T12:04:57.923 に答える
17

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

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

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

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

于 2010-05-19T13:51:38.680 に答える
11

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

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

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

次のものよりもはるかに読みやすいか、または読みにくいです。

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
于 2009-06-09T19:10:37.817 に答える
10

VARの重要な点は、適切な場合にのみ使用することです。つまり、Linqで実行しやすい場合(およびおそらく他の場合)にのみ使用することです。

何かのタイプがある場合は、それを使用する必要があります-そうしないことは単純な怠惰です(一般的に奨励される創造的な怠惰とは対照的に-優れたプログラマーは怠惰になるために非常に一生懸命働くことが多く、考慮される可能性がありますそもそも物の出所)。

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

もう1つ覚えておくべきことは、型を変更できないという点でVB型変数でないということです。これは、型が推測されるというだけの強い型付き変数です(そのため、不合理ではないと主張する人がいます。たとえば、foreachで使用しますが、読みやすさと保守性の両方の理由から同意しません)。

これは実行されて実行されると思います(-:

マーフ

于 2008-09-03T11:47:35.453 に答える
10

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

于 2010-05-19T13:54:09.203 に答える
9

この問題に関する CodingHorrorの投稿から盗んだもの:


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

MyObject m = new();

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

Person p = new("FirstName", "LastName);

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

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

Nicholas Paldino .NET/C# MVP 2008 年 6 月 20 日午前 8 時


あなたの主な関心事がタイプを少なくすることである場合、それを使用することを妨げる議論はありません。

あなたが自分のコードを見るだけの人になるつもりなら、誰が気にしますか? それ以外の場合は、次のようになります。

var people = Managers.People

問題ありませんが、次のような場合です。

var fc = Factory.Run();

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

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

于 2008-12-24T14:51:13.420 に答える
9

明示的な型の代わりに使用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());
...

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

于 2009-08-19T07:21:36.290 に答える
8

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

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

于 2008-09-03T12:02:03.080 に答える
8

それは好みの問題です。動的に型付けされた言語に慣れると、変数のに関するこのような煩わしさはなくなります。つまり、あなたがそれらを好きになり始めたら(誰もができるかどうかはわかりませんが、私はそうします)。

C#は、動的型付けのように見えるvarという点で非常に優れていますが、実際には静的型付けです。コンパイラーは正しい使用法を強制します。

変数のタイプはそれほど重要ではありません(これは以前に言われています)。コンテキスト(他の変数やメソッドとの相互作用)とその名前から比較的明確である必要があります-customerListに...が含まれていることを期待しないintください。

上司がこの問題についてどう思うかをまだ待っています。3.5で新しい構成を使用するためのブランケットを「先に進め」ましたが、メンテナンスについてはどうしますか?

于 2008-09-03T12:10:53.463 に答える
7

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

動的でvarないため、型安全性についての懸念はありません。これは単なるコンパイラの魔法であり、タイプセーフでない呼び出しはすべてキャッチされます。

VarLinqには絶対に必要です:

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
    };

intellisense で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# コンパイラは非常に巧妙です。個別に生成された anon 型は、それらのプロパティが一致する場合、生成された型が同じになります。

それ以外では、IntelliSense がある限り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;
于 2008-09-03T12:13:33.020 に答える
7

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

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

var x = new MyClass();

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

var x = MyClass.MyFunction();

特に、右側がメソッドではなく、値のみである場合は、var を使用しません

var x = 5;

(コンパイラは、byte、short、int などが必要かどうかを認識できないため)

于 2010-05-19T14:09:30.927 に答える
7

それはあなたの見方次第だと思います。私は個人的に、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

対処するのが本当に不可能だった場合、動的型付け言語を使用する人は誰もいませんでした。

于 2009-06-09T19:08:54.967 に答える
6

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

StringBuilder sb = new StringBuilder();

よりも

var sb = new StringBuilder();

あなたが私を信じていないなら、それらを数えてください...

19対21

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

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

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

于 2010-03-11T18:27:24.287 に答える
6

私にとって、に対する反感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が行うことです。

于 2008-09-19T20:45:41.443 に答える
6

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

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

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

私は動的型付けを気にしませんし、暗黙的型付けも気にしません - 彼らのために設計された言語で。私はかなりパイソンが好きです。しかし、C# は静的に明示的に型指定された言語として設計されており、そのままにしておく必要があります。匿名型のルールを破ることは十分に悪いことでした。人々がそれをさらに進めて、言語のイディオムをさらに壊すことは、私が満足していないことです. 魔神が瓶から出た今、それは二度と元に戻ることはありません.C#はキャンプに分断されます. 良くない。

于 2008-09-25T14:34:59.677 に答える
6

テスト中に何度も、次のようなコードを見つけました。

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 がなければ、左側でも宣言された型を変更し続ける必要があります。些細なこととは存じますが、非常に便利です。

于 2009-06-09T19:15:54.280 に答える
5

int i = 3;私は var をあらゆる場所に分割しました。私にとって疑わしい場所は内部の短い型だけです。var i = 3;

于 2008-09-03T12:13:43.380 に答える
5

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

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

がなければ、これは非常に冗長になりvarます。

補遺:真の型推論 (F# など) を備えた言語で少し時間を費やすと、コンパイラが式の型を正しく取得するのにいかに優れているかがわかります。確かに、varできる限り多くを使用する傾向があることを意味しており、明示的な型を使用することは、変数が初期化式の型ではないことを示しています。

于 2009-06-09T19:12:18.890 に答える
5

以前は var キーワードは素晴らしい発明だと思っていましたが、これに制限を加えました。

  • 型がすぐにわかる場合にのみ var を使用します (スクロールしたり、戻り値の型を調べたりする必要はありません)。

私はこれが何の利益ももたらさないことに気づき、私のコードからすべての var キーワードを削除しました (特に必要な場合を除きます)。

これは意図を隠し、少なくとも 1 つのインスタンスでは、型の仮定が原因で、一部のコードで実行時のバグにつながります。

于 2009-09-02T13:20:38.947 に答える
5

型名を 2 回記述する必要がないことを除いて、なし。http://msdn.microsoft.com/en-us/library/bb383973.aspx

于 2009-08-19T07:09:08.640 に答える
5

ほとんどの場合、入力する方が簡単です-想像してみてください

var sb = new StringBuilder();

それ以外の:

StringBuilder sb = new StringBuilder();

場合によっては、必要になることもあります。たとえば、匿名型などです。

var stuff = new { Name = "Me", Age = 20 };

コードの可読性と保守性が低下するという事実にもかかわらず、私は個人的にそれを使用するのが好きです.

于 2009-08-19T07:09:32.150 に答える
4

LINQ を使用するもう 1 つの非常に適切な理由varは、コンパイラがクエリをさらに最適化できることです。

静的リストを使用して結果を保存すると、リストに割り当てた場所で実行されますvarが、元のクエリをコード内の後のクエリとマージして、データベースに対してより最適化されたクエリを作成できる可能性があります。

最初のクエリでいくつかのデータを取得し、ループしてテーブルを印刷するために追加のデータを要求した例がありました。

LINQ はこれらをマージして、最初の id のみを取得するようにします。

次に、ループ内で、オリジナルに含まれていたデータをフェッチするために、そこで行っていなかった追加の結合を追加しました。

テストしたところ、これははるかに効率的であることが証明されました。

使用varしていなければ、作成したとおりにクエリが作成されていました。

于 2010-10-25T10:01:27.963 に答える
3

varキーワードを使い始めたときも同じ心配がありました。
しかし、私は時間の経過とともにそれに慣れ、明示的な変数型に戻るつもりはありませんでした。VisualStudioのcompiler\integersenseは、暗黙的に型指定された変数の操作をはるかに簡単にする上で非常に優れた仕事をしています。

適切な命名規則に従うと、明示的な入力よりもコードをよりよく理解するのに役立つと思います。

「変数名にプレフィックスを使用する必要がありますか?」のような同じ種類の質問のようです。
適切な変数名に固執し、コンパイラに変数の型について考えさせます。

于 2008-09-03T11:36:00.927 に答える
3

誰かがvarの批判を好まない..すべての答えがダウンモッド..まあ..

@Jon Limjap:わかっています。:)私が言いたかったのは、VB6のように読みやすさが低下するということでした。特定の変数がどのタイプであるかを理解するためにIntellisenseに依存するのは好きではありません。ソースだけで把握できるようにしたいと思います。

命名規則も役に立ちません-私はすでに良い名前を使用しています。プレフィックスに戻りますか?

于 2008-09-03T11:45:04.040 に答える
3

このトピックに関する議論から、結果は次のようになります。

良い:var customers = new List<Customer>();

物議を醸す:var customers = dataAccess.GetCustomers();

「var」が魔法のようにリファクタリングに役立つという誤った意見を無視すると、私にとって最大の問題は、「コレクションを列挙できる限り」、リターンタイプが何であるかを気にしないという人々の主張です。

検討:

IList<Customer> customers = dataAccess.GetCustomers();

var dummyCustomer = new Customer();
customers.Add(dummyCustomer);

今考えてみましょう:

var customers = dataAccess.GetCustomers();

var dummyCustomer = new Customer();
customers.Add(dummyCustomer);

次に、データアクセスクラスに移動してリファクタリングし、GetCustomersがを返すようにしてIEnumerable<Customer>、何が起こるかを確認します...

ここでの問題は、最初の例では、GetCustomersメソッドへの期待を明示的にしていることです。つまり、リストのように動作するものを返すことを期待しているということです。2番目の例では、この期待は暗黙的であり、コードからすぐにはわかりません。

多くのpro-var引数が「どのタイプが返されるかは気にしない」と言っているのは興味深いですが、「それを繰り返す必要があるだけです...」と続けてください。(したがって、IEnumerableインターフェイスを実装する必要があり、タイプ重要であることを意味します)。

于 2009-11-12T17:44:55.103 に答える
3

私は、Java の専門家として 10 年を過ごした後、C# の世界ではかなり新しいものです。私の最初の考えは、「ああ、型の安全性が失われる」というものでした。しかし、var について読めば読むほど、好きになります。

1) Var は、明示的に宣言された型と同じように、あらゆる点で型安全です。コンパイル時の構文糖衣がすべてです。

2) DRY の原則に従います (同じことを繰り返さないでください)。DRY は冗長性を避けることがすべてであり、両側で型に名前を付けるのは確かに冗長です。冗長性を回避することは、コードを変更しやすくすることです。

3) 正確な型を知ることに関しては..そうですね..整数、ソケット、何らかの UI コントロールなどを持っているという一般的な考えを常に持っていると私は主張します。ここからインテリセンスが案内してくれます。多くの場合、正確なタイプを知っていても問題ありません。たとえば、与えられた変数が long なのか int なのか、fl​​oat なのか double なのか、99% の時間は気にしないと私は主張します。本当に重要な最後の 1% のケースでは、マウス ポインタを var キーワードの上に置いてください。

4) 変数の型を区別するために、1980 年式のハンガリーの疣贅に戻る必要があるというばかげた議論を見てきました。結局、ティモシー・ダルトンがジェームズ・ボンドを演じた時代には、これが変数の型を伝える唯一の方法でした。しかし、これは 2010 年のことです。変数の使用法と内容に基づいて変数に名前を付ける方法を学び、IDE にその型を案内してもらいました。これを続けるだけで、var があなたを傷つけることはありません。

要約すると、var は大したことではありませんが、非常に優れた機能であり、Java がすぐにコピーした方がよい機能です。反対するすべての議論は、IDE以前の誤謬に基づいているようです。私はそれを使用することを躊躇しません.R#が私を助けてくれることをうれしく思います.

于 2010-10-26T06:00:34.243 に答える
3

var は、子供向けの本で子供が埋めなければならない点線のスペースのようなものです。この場合を除いて、コンパイラは通常 = 記号の後に書かれる正しい型でそれを埋めます。

于 2011-11-23T03:04:12.693 に答える
3

I use var whenever possible.

The actual type of the local variable shouldn't matter if your code is well written (i.e., good variable names, comments, clear structure etc.)

于 2009-01-28T16:55:12.300 に答える
3

ええと、これはかなり一貫して意見が分かれるでしょうが、私はそれについて私の見解を述べようとします-私の見解は非常に混乱しているので、とにかくあなたはおそらくそれからあまり得られないと思います.

まず第一に - 匿名型があり、そのクラスとして匿名型を持つオブジェクトを割り当てるために "var" キーワードを使用する必要があります - ここでは多くの議論はありません. "var" が必要です.

ただし、int、long、string などの単純な型については、適切な型を使用する傾向があります。主な理由は、これはちょっとした「怠け者のツール」であり、ここであまりメリットが見られないためです。キーストロークが非常に少なく、後で混乱する可能性があるため、それだけの価値はありません。特に、浮動小数点数のさまざまなタイプ (float、double、decimal) は、リテラルの接尾辞に自信がないため、混乱します。ソース コードでタイプを確認したいのです。

そうは言っても、型がより複雑である場合、および/または割り当ての右側で明示的に繰り返される場合、私は var alot を使用する傾向があります。これは、次のList<string>ようなまたはなどである可能性があります。

var list = new List<string>();

そのような場合、型を 2 回繰り返す必要はありません。特に、コードを変更し始めて型が変更されると、ジェネリック型はますます複雑になる可能性があるため、2 回変更する必要があるのは苦痛です。ただし、もちろん、 に対してコーディングしたい場合はIList<string>、型に明示的に名前を付ける必要があります。

要するに、私は次のことを行います。

  • 型が短い場合、または文脈から読み取ることができない場合は、型に明示的に名前を付けます
  • 使用する必要がある場合は var を使用してください (duh)
  • (私の考えでは)読みやすさを損なわない場合は、 var を使用して怠惰にします
于 2010-05-19T13:53:10.483 に答える
3

それは純粋に便利です。コンパイラは、(右側の式の型に基づいて) 型を推測します。

于 2009-08-19T07:09:27.827 に答える
2

読みやすさの問題とは別に、「var」の使用には1つの実際の問題があります。コードの後半で割り当てられる変数を定義するために使用される場合、変数の初期化に使用される式のタイプがより狭いタイプに変更されると、コードが破損する可能性があります。通常、メソッドをリファクタリングして、以前よりも狭い型を返すのが安全です。たとえば、戻り型の「Object」をクラス「Foo」に置き換えます。ただし、メソッドに基づいて型が推測される変数がある場合、戻り型を変更すると、この変数に非Fooオブジェクトを割り当てることができなくなります。

var x = getFoo(); // Originally declared to return Object
x = getNonFoo();

したがって、この例では、getFooの戻りタイプを変更すると、getNonFooからの割り当てが無効になります。

getFooとそのすべての用途が同じプロジェクトにある場合、これはそれほど大きな問題ではありませんが、getFooが外部プロジェクトで使用するライブラリにある場合、戻り値のタイプを絞り込んでも一部のユーザーコードが破損しないことを確認できなくなります。彼らはこのように「var」を使用します。

同様の型推論機能をCurlプログラミング言語(Curlでは「def」と呼ばれる)に追加したときに、この構文を使用して定義された変数への割り当てを防止したのは、まさにこの理由によるものです。

于 2010-05-19T14:21:45.127 に答える
2

C#でのvarの使用法を誤解しているかもしれません。VBバリアントタイプとは異なり、強いタイピングであるため、使用するかどうかによるパフォーマンスへの影響はありません。

最終的にコンパイルされたコードには影響がないため、実際にはスタイリストが選択します。個人的には、完全な型が定義されているとコードが読みやすくなるため、使用しませんが、数年後には、完全な型の宣言がハンガリアン記法と同じように見られるようになると想像できます-インテリセンスがデフォルトで提供する情報に対して実際の利益をもたらさないための追加の入力。

于 2010-05-19T13:50:00.423 に答える
2

var驚いたことに、これまで注目されていませんでしたが、 forforeachループ変数を使用するのは常識です。

代わりに特定の型を指定すると、ランタイム キャストがコンパイラによって暗黙のうちにプログラムに挿入される危険があります。

foreach (Derived d in listOfBase)
{

上記がコンパイルされます。しかし、コンパイラはダウンキャスト from Baseto を挿入しDerivedます。そのため、リストDerivedに実行時にないものがある場合は、無効なキャスト例外があります。型の安全性が損なわれています。目に見えないキャストは恐ろしいです。

これを除外する唯一の方法は を使用することですvar。そのため、コンパイラはリストの静的な型からループ変数の型を決定します。

于 2010-04-30T17:22:51.267 に答える
2

varanonymous typesは、 C# 3.0 および LINQ で導入されたプレースホルダーです。

そのため、たとえばコレクション内の少数の列に対して LINQ クエリを作成できます。メモリ内の情報を複製する必要はありません。実行する必要があることを達成するために必要なものだけをロードします。

の使用varはまったく悪くありません。実際には型ではありませんが、他の場所で述べたように、式の右辺で定義する必要がある型のプレースホルダーです。次に、コンパイラはキーワードを型自体に置き換えます。

これは、IntelliSense を使用しても型の名前を入力するには長い場合に特に便利です。と書いvarてインスタンス化するだけです。後でコードを読む他のプログラマーは、あなたが何をしているのかを簡単に理解できます。

使うようなものです

public object SomeObject { get; set; }

それ以外の:

public object SomeObject {
    get {
        return _someObject;
    } 
    set {
        _someObject = value;
    }
}
private object _someObject;

誰もがvarキーワードが何をしているのかを知っているので、プロパティが何をしているのかを誰もが知っています。どちらの例も、より軽くすることで可読性を容易にし、プログラマーが効果的なコードを書くことをより快適にします。

于 2010-05-19T15:20:25.683 に答える
2

静的型付けは、ソース コードではなく、コントラクトに関するものです。小さなメソッドである「はず」の1行に静的情報を含める必要があるという考え。一般的なガイドラインでは、メソッドごとに 25 行を超えることはめったにありません。

メソッドが十分に大きいため、そのメソッド内の単一の変数を追跡できない場合は、比較すると var に対する批判が見劣りするような別のことをしているということです。

実際、var の重要な議論の 1 つは、宣言を過度に制限したことを心配する必要がなくなるため (つまり、IList<> または IEnumerable<> を使用する必要があるときに List<> を使用した)、リファクタリングが簡単になるということです。 )。新しいメソッド シグネチャについても考えたいと思いますが、少なくとも、前に戻って宣言を一致するように変更する必要はありません。

于 2008-09-11T01:31:02.433 に答える
2

3.0 および 3.5 フレームワークに変換した直後に、このキーワードについて学び、試してみることにしました。コードをコミットする前に、ASP 構文に戻ったように、逆方向に見えることに気付きました。そこで私は、上層部が何を考えているかを確認するために突っ込むことにしました。

彼らは先に行くと言ったので、私はそれを使用します。

そうは言っても、次のように、タイプが調査を必要とする場所では使用しないでください。

var a = company.GetRecords();

これは単なる個人的なものかもしれませんが、すぐにそれを見て、それが Record オブジェクトのコレクションなのか、それともレコードの名前を表す文字列配列なのかを判断することはできません。いずれにせよ、明示的な宣言はそのような場合に役立つと思います。

于 2008-09-03T13:46:04.843 に答える
2

エッジケースの近くでは意見の相違があるに違いありませんが、私の個人的なガイドラインをお伝えすることができます.

を使用することにしたとき、これらの基準を確認しますvar

  • 変数の型はコンテキストから [人間には]明らかです
  • 変数の正確なタイプは、[人間にとって]特に関係ありません
    [たとえば、使用しているコンテナの種類を気にせずにアルゴリズムが何をしているのかを理解できます]
  • 型名が非常に長く、コードの可読性を妨げています (ヒント: 通常はジェネリック)

逆に、これらの状況では、使用しないように促されますvar

  • 型名は比較的短く、読みやすいです (ヒント: 通常はジェネリックではありません) 。
  • タイプは初期化子の名前から明らかではありません
  • コード/アルゴリズムを理解するには、正確な型が非常に重要です。
  • クラス階層で、人間が階層のどのレベルが使用されているかを簡単に判断できない場合

最後に、varネイティブの値型または対応するnullable<>型 ( intdecimalstringdecimal?...) には使用しません。varを使用する場合は、「理由」があるに違いないという暗黙の前提があります。

これらはすべてガイドラインです。また、同僚の経験とスキル、アルゴリズムの複雑さ、変数の寿命/範囲などについても考慮する必要があります。

ほとんどの場合、完全な正解はありません。または、それは本当に問題ではありません。

[編集:重複する箇条書きを削除]

于 2009-06-09T19:33:54.167 に答える
2

あなたの質問で var の主な問題を指摘していると思います:「型を理解する必要はありません」。他の人が指摘したように、var の場所がありますが、扱っている型がわからない場合は、将来的に問題が発生する可能性がかなり高くなります。すべての場合ではありませんが、しかし、そこには十分なにおいがあるので、疑わしいはずです。

于 2010-05-19T13:52:37.477 に答える
1

コンパイラーは、開発者よりも「優れた」必要なものを推測できる場合もあります。少なくとも、使用しているAPIが何を必要としているかを理解していない開発者です。

例-linqを使用する場合:

例1

Func<Person, bool> predicate = (i) => i.Id < 10;
IEnumerable<Person> result = table.Where(predicate);

例2

var predicate = (Person i) => i.Id < 10;
var result = table.Where(predicate);

上記のコードでは、LinqtoNhibernateまたはLinqtoSQLを使用していると仮定すると、例1では、Personオブジェクトの結果セット全体が返され、クライアント側でフィルター処理が行われます。ただし、例2は、サーバー(SQLを使用するSql Serverなど)でクエリを実行します。コンパイラーは、Where関数がFuncではなくExpression>を使用する必要があることを理解するのに十分賢いからです。

例1の結果は、IEnumerableが返されるため、サーバー上でそれ以上クエリ可能ではありませんが、例2では、​​結果がIEnumerableではなくIQueryableであるかどうかをコンパイラーが判断できます。

于 2009-08-19T09:17:35.603 に答える
1

kronoz-その場合(両方の過負荷)それは重要ですか?異なるタイプをとる2つのオーバーロードがある場合、基本的にはどちらかを渡して同じことを行うことができると言っているでしょう。

渡されたタイプに応じて完全に異なるアクションを実行する2つのオーバーロードがあってはなりません。

その場合、混乱を招く可能性がありますが、それでも完全にタイプセーフですが、誰かが間違ったメソッドを呼び出しているだけです。

于 2008-09-04T12:23:15.267 に答える
1

私たちのオフィスでは、あなたが述べたのと同じ理由で、CTOがvarキーワードの使用を断固として禁止しています。

個人的には、オブジェクトのタイプはステートメント自体で明らかであるため、varの使用は新しいオブジェクト宣言でのみ有効であることがわかります。

LINQクエリの場合、結果を次のように解決できます。

IEnumerable<TypeReturnedBySelectObject>
于 2008-09-03T11:35:49.320 に答える
1

@ erlando、好奇心から、なぜソースコードを見て変数の型を知る必要があるのですか?

私の練習では、変数の型は、コードで使用しているときにのみ問題になることがわかりました。

someVarコンパイラで不適切な操作を行おうとすると、エラー\警告が表示されます。

与えられたコンテキストでsomeVarが使用されている理由を理解していれば、someVarのタイプは本当に気になりません。

于 2008-09-03T11:55:57.167 に答える
1

この議論に少し遅れて到着しましたが、私はただ考えを追加したいと思います。

型推論に反対しているすべての人にとって(ここで実際に話しているのはそれだからです)、ラムダ式はどうですか?常に型を明示的に宣言することを主張する場合(匿名型を除く)、ラムダで何をしますか?「マウスオーバーを使用させない」引数はvarには適用されますが、ラムダには適用されませんか?

アップデート

まだ誰も言及していないと思う「var」に対する1つの引数について考えました。これは、「すべての参照を検索」を「壊す」ということです。これは、たとえば、使用法をチェックしている場合に意味する可能性があります。リファクタリングする前のクラスの場合、を介してクラスが使用されたすべての場所を見逃すことになりますvar

于 2009-04-27T09:09:18.157 に答える
1

私の意見では、多用しても問題ありませんvar。それはそれ自身のタイプではありません(あなたはまだ静的型付けを使用しています)。代わりに、それは単なる時間の節約であり、コンパイラーに何をすべきかを理解させます。

他の時間の節約(たとえば、自動プロパティなど)と同様に、どこでも使用する前に、それ何であるか、およびどのように機能するかを理解することをお勧めします。

于 2010-05-19T13:49:32.813 に答える
1

var悪くない。これを覚えて。var悪くない。繰り返す。var悪くない。これを覚えて。var悪くない。繰り返す。

コンパイラがコンテキストから型を理解するのに十分賢いなら、あなたもそうです。宣言時にすぐに書き留めておく必要はありません。そして、インテリセンスはそれをさらに少なくします。

var悪くない。これを覚えて。var悪くない。繰り返す。var悪くない。これを覚えて。var悪くない。繰り返す。

于 2010-05-19T13:51:05.103 に答える
1

なぜ人々がこのような議論を始めるのか理解できません。何も得られない炎の戦いを開始する以外に、それは実際には何の役にも立たない。C# チームが 1 つのスタイルを段階的に廃止して別のスタイルを採用しようとした場合、各スタイルのメリットについて議論する理由がわかります。しかし、どちらも言語に残るので、好きな方を使用して、全員に同じようにさせてはいかがでしょうか。これは、誰もが好きな三項演算子を使用するようなものです。好きな人もいれば嫌いな人もいます。結局のところ、コンパイラには何の違いもありません。

これは、どちらが好きな親かをめぐって兄弟と口論するようなものです: 離婚しない限り、それは問題ではありません!

于 2008-09-09T12:55:29.747 に答える
1

コンパイラ (および次にコードを保守する仲間) に、初期化子割り当ての右側から型を推測させることができます。この推論が可能である場合、コンパイラはそれを行うことができるため、入力の手間が省けます。

その可哀想な人にとって推論が簡単であるなら、あなたは何も傷つけていません。推論が難しい場合は、コードの保守が難しくなっていることになるため、原則として、私はそうしません。

最後に、型を特定のものにするつもりで、初期化式が実際には別の型を持っている場合、var を使用すると、誘発されたバグを見つけるのが難しくなります。意図した型をコンパイラに明示的に伝えることで、型がそうでない場合は、すぐに診断を受けることができます。型宣言を省略して「var」を使用すると、初期化時にエラーが発生しなくなります。代わりに、var 式によって割り当てられた識別子を使用する式で型エラーが発生し、その理由を理解するのが難しくなります。

したがって、教訓は、var を控えめに使用することです。あなたは通常、自分自身や下流の仲間のメンテナーに多くの利益をもたらしていません。そして、彼が同じように推論することを願っています。寿命の長いシステムをコーディングする場合、入力量を最適化するのは間違いです。

于 2009-08-19T07:25:07.610 に答える
1

タイプがわかっている場合は、そのタイプを使用します。タイプがわからない場合は、なぜですか?型がわからない場合でも問題ありません。唯一の有効な使用方法を見つけたことになります。

申し訳ありませんが、「コードをすべて揃える」ことが最善の方法である場合、それは良い答えではありません。コードをフォーマットする別の方法を見つけてください。

于 2010-05-19T16:27:35.200 に答える
1

ほとんどの人が無視しているもの:

var something = new StringBuilder(); 

通常はそれほど速く入力されません

StringBuilder something = KEY'TAB'();
于 2010-08-12T09:53:44.890 に答える
1

「var」キーワードをスキップすることに慣れているだけなので、var キーワードを使用すると実際にコードが読みやすくなることがわかりました。特定のタイプが何であるかを本当に気にしない場合、コードが何をしているのかを理解するために右にスクロールし続ける必要はありません。下にある「項目」のタイプを本当に知りたい場合は、マウスをその上に置くだけで、Visual Studio が教えてくれます。言い換えれば、私はむしろ読みたい

foreach( var item in list ) { DoWork( item ); }

何度も何度も

foreach( KeyValuePair<string, double> entry in list ) { DoWork( Item ); }

コードを消化しようとしているとき。ある程度は個人の好みによると思います。私はこれについて常識に頼ります-重要なもの(セキュリティ、データベースの使用、ロギングなど)の強制基準を保存します

-アラン。

于 2008-09-15T21:20:47.987 に答える
1

私はマット・ハミルトンに同意しなければなりません。

Var を適切な変数名と一緒に使用すると、コードをより読みやすく理解しやすくすることができます。しかし、var は、使い方を誤ると、コードを Perl のように読みにくく、理解できなくすることもあります。

var の良い使い方と悪い使い方のリストもあまり役に立ちません。これは常識のケースです。より大きな問題は、読みやすさと書き込み能力の 1 つです。多くの開発者は、コードが読み取り可能かどうかを気にしません。彼らはあまりタイプしたくないだけです。個人的には、私は読み取り > 書き込み派です。

于 2008-09-03T15:54:37.373 に答える
1

次の状況で var を使用します。

  1. 私がしなければならないとき(結果は匿名です)
  2. タイプがコードと同じ行にある場合。

    var emp = 新しい従業員();

Employee が必要であることは明らかです (新しい Employee オブジェクトを作成しているため)。

Employee emp = new Employee() any more obvious?

型を推測できない場合、私は var を使用しません。

var emp = GetEmployee();

戻り値の型がすぐにはわからないためです (Employee、IEmployee、Employee オブジェクトとはまったく関係のないものなど)。

于 2008-09-03T13:43:31.587 に答える
1

人々は var キーワードを理解していないと思います。彼らはそれを Visual Basic / JavaScript キーワードと混同していますが、これはまったく別の獣です。

var キーワードは弱い型付け (または動的型付け) を意味すると多くの人が考えていますが、実際には c# は厳密に型付けされたままです。

これをJavaScriptで考えると:

var something = 5;

次のことが許可されています。

something = "hello";

C# の場合、コンパイラは最初のステートメントから型を推測し、何かが "int" 型になるため、2 番目のステートメントで例外が発生します。

var キーワードを使用することは動的型付けを意味するものではないことを理解し、var キーワードをどこまで使用するかを決定する必要があります。コンパイルされる内容にまったく違いがないことを知っているからです。

確かに匿名型をサポートするために var キーワードが導入されましたが、これを見ると:

LedDeviceController controller = new LedDeviceController("172.17.0.1");

それは非常に冗長であり、これはそれ以上ではないにしても、同じくらい読みやすいと確信しています。

var controller = new LedDeviceController("172.17.0.1");

結果はまったく同じなので、はい、コード全体で使用します

アップデート:

たぶん、たぶん...彼らは別のキーワードを使用するべきだったのなら、この議論は行わないでしょう...おそらく「var」の代わりに「infered」キーワードを使用するでしょう

于 2008-10-17T20:20:01.903 に答える
1

vars を単なる「入力のショートカット」として使用するべきではなく、主に設計されたシナリオに使用する必要がある理由の 1 つを説明します。Resharper (少なくとも v4.5) は、型が変数。これは、ソース コードをリファクタリングまたは分析する際に実際の問題になる可能性があります。

于 2010-07-20T09:14:43.630 に答える
1

冗長性のために削除されました。

varsは引き続き正しい変数型として初期化されます。コンパイラはコンテキストからそれを推測するだけです。ほのめかしたように、var を使用すると、匿名クラス インスタンスへの参照を格納できますが、コードの変更も簡単になります。例えば:

// If you change ItemLibrary to use int, you need to update this call
byte totalItemCount = ItemLibrary.GetItemCount();

// If GetItemCount changes, I don't have to update this statement.
var totalItemCount = ItemLibrary.GetItemCount();

はい、名前と使用方法から変数の型を判断するのが難しい場合は、必ずその型を明示的に宣言してください。

于 2010-05-19T13:48:28.930 に答える
0

ジェフ・イェーツが説明したようなコードで毎日使用しているので、varpersayはひどい言語機能ではないと思います。実際、私がvarを使用するほとんどの場合、ジェネリックは非常に言葉の多いコードを作成できるためです。私は冗長なコードを使用していますが、ジェネリックスはそれを一歩進めすぎています。

そうは言っても、私は(明らかに...)varは悪用に熟していると思います。変数が散らばっているメソッドでコードが20行以上になると、すぐにメンテナンスが悪夢になります。さらに、チュートリアルのvarは非常に直感的ではなく、一般的に私の本では大したことではありません。

逆に言えば、varは、新しいプログラマーが夢中になれる「簡単な」機能です。その後、数分/時間/日以内に、限界に達し始めたときに大きな障害にぶつかります。「関数からvarを返されないのはなぜですか?」そのような質問です。また、強い型の言語に疑似動的型を追加することは、新しい開発者を簡単につまずかせる可能性があります。長期的には、varキーワードを使用すると、実際には新しいプログラマーがc#を習得するのが難しくなると思います。

とは言うものの、経験豊富なプログラマーとして、私は主にジェネリックス(そして明らかに匿名型)を扱うときにvarを使用します。私は私の引用を保持します、私はvarが最悪の悪用されたc#機能の1つになると信じています。

于 2009-06-09T19:20:33.757 に答える
0

@ erlando、

リファクタリングについて言えば、複数の場所で変更するよりも、新しい型のインスタンスを1つの変数に割り当てる方が、変数の型を変更する方がはるかに簡単なようです。

コードレビューに関しては、 varキーワードに大きな問題は見られません。コードレビューでは、変数タイプではなくコードロジックをチェックすることを好みます。もちろん、開発者が不適切なタイプを使用できるシナリオもあるかもしれませんが、そのようなケースの数は非常に少ないので、varキーワードの使用をやめる理由にはならないと思います。

だから私は私の質問を繰り返します。なぜ可変型があなたにとって重要なのですか?

于 2008-09-03T12:07:46.967 に答える
0

初め。

varはタイプではなく、特別な機能(c#4.0などdynamic)でもありません。これは単なるシンタックスシュガーです。コンパイラに、右辺の式で型を推測するように依頼します。唯一必要な場所は匿名タイプです。

var使用することは良いことでも悪いことでもないと思います。それはコーディングスタイルです。個人的には使用していませんが、他のチームメンバーが使用してもかまいません。

于 2010-05-19T13:52:21.587 に答える
0

var は、LINQ ステートメントからかどうかに関係なく、匿名型を処理する方法です。他の使用法は、誰がコードを読むか、およびどのようなガイドラインが整備されているかに大きく依存します。

あなたが唯一の聴衆であるか、聴衆が var の使用に慣れているか、コードに非常に精通している場合、それは問題ではないと思います. var s = new SqlConnection() のように使用すると、ほとんど問題にならず、おそらくコードの読みやすさが向上します。人々がうるさくなく、タイプが明らかでない場合にタイプを知るために少し作業をしても問題ない場合 (ほとんどの場合、これは必要ありません。次のステートメントでの使用方法で通常すべてが説明されます)、問題ありません。 .

しかし、うるさい、気難しいチームメイトが泣き言を言うのが好きな場合や、会社の設計ガイドラインで型が明らかでない場合に var を使用することを明確に禁止している場合は、おそらく激しい反対に遭うでしょう。

var を使用するとコードが非常に読みにくくなる場合は、アプリの設計に問題があるとしても、おそらく var を使用することで撃たれるでしょう。

var があいまいさを導入する場合 (IEnumerable/IEnumerable の例のようなもの)、それを使用せず、明示的にしてください。しかし、var には便利な点があり、場合によっては、IMHO は混乱を減らすことで可読性を向上させることさえあります。

于 2011-11-21T05:41:27.640 に答える
0

var繰り返したくないときに最適です。たとえば、昨日、これに似たデータ構造が必要でした。あなたはどちらの表現が好きですか?

Dictionary<string, Dictionary<string, List<MyNewType>>> collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

また

var collection = new Dictionary<string, Dictionary<string, List<MyNewType>>>();

varこの例で使用することによって導入されるあいまいさはほとんどないことに注意してください。ただし、あまり良い考えではない場合もあります。たとえばvar、次のように使用した場合、

var value= 5;

本当の型を書くだけで、表現方法のあいまいさを取り除くことができたとき5

double value = 5;
于 2009-06-09T19:11:36.427 に答える
0

var古典的なDRYルールに従っているので良いですし、変数を宣言するのと同じ行で型を指定すると特にエレガントです。(例var city = new City())

于 2010-05-19T16:03:14.943 に答える
0

ローカル変数には、明示的な型ではなく、推論された var の「型」を指定できます。var キーワードは、初期化ステートメントの右側の式から変数の型を推測するようコンパイラーに指示します。

// z は int としてコンパイルされます

var z = 100;

// s は以下の文字列としてコンパイルされます

var s = "Hello";

// a は int[] としてコンパイルされます

var a = new[] { 0, 1, 2 };

// expr は IEnumerable としてコンパイルされます // またはおそらく IQueryable

var expr =
    from c in customers
    where c.City == "London"
    select c;

// anon は匿名型としてコンパイルされます

var anon = new { Name = "Terry", Age = 34 };

// リストは List としてコンパイルされます

var list = new List<int>();

var can only be used when a local variable is declared and initialized in the same statement; the variable cannot be initialized to null, or to a method group or an anonymous function.

var は、クラス スコープのフィールドでは使用できません。

var を使用して宣言された変数は、初期化式では使用できません。つまり、次の式は正当です。 int i = (i = 20); しかし、この式はコンパイル時エラーを生成します: var i = (i = 20);

複数の暗黙的に型指定された変数を同じステートメントで初期化することはできません。

var という名前の型がスコープ内にある場合、var キーワードはその型名に解決され、暗黙的に型指定されたローカル変数宣言の一部として扱われません。

于 2011-11-28T09:59:08.577 に答える
0

C# のルーツである C/C++/Java に反するため、var は使用しません。これはコンパイラのトリックですが、言語があまり強く型付けされていないように感じさせます。おそらく、20年以上のCの経験により、等号の左側と右側の両方に型を持たなければならないということが、私たち(反varの人々)の頭にすべて染み込んでいます。

長い一般的なコレクション定義と、codinghorror.com の例のような長いクラス名のメリットはわかりますが、string/int/bool などの他の場所では、ポイントがわかりません。特に

foreach (var s in stringArray)
{

}

3キャラ節約!

私にとっての主な煩わしさは、メソッドにカーソルを合わせるか F12 キーを押さない限り、メソッド呼び出しの var が表す型を確認できないことです。

于 2009-01-31T11:54:34.210 に答える
0

@キース -

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

それは完全に真実ではありません-メソッドが IEnumerable<int> と IEnumerable<double> の両方にオーバーロードされている場合、(プログラムの他の変更により) 予期しない推論された型を暗黙のうちに間違ったオーバーロードに渡し、誤った動作を引き起こす可能性があります。 .

問題は、このような状況がどの程度発生する可能性があるかということです。

問題の一部は、指定された宣言に var がどれだけ混乱をもたらすかということだと思います-何かの型が明確でない場合 (強く型付けされていて、コンパイラーがそれが何であるかを完全に理解しているにもかかわらず)、誰かが型安全エラーを見逃している可能性があります。少なくともコードを理解するのに時間がかかります。

于 2008-09-03T13:16:09.533 に答える
0

Essential LINQから:

どうしても必要な場合を除き、範囲変数の型を明示的に宣言しないことをお勧めします。たとえば、次のコードは正常にコンパイルされますが、型は正式な宣言なしでコンパイラによって推測された可能性があります。

List<string> list = new List<string> { "LINQ", "query", "adventure" };
var query = from string word in list
      where word.Contains("r")
      orderby word ascending
      select word;

範囲変数の型を明示的に宣言すると、裏で LINQ Cast 演算子が強制的に呼び出されます。この呼び出しは、意図しない結果をもたらす可能性があり、パフォーマンスが低下する可能性があります。LINQ クエリでパフォーマンスの問題が発生した場合は、ここに示すようなキャストを使用して、原因を探し始めることができます。(この規則の 1 つの例外は、非ジェネリックの Enumerable を使用する場合です。この場合は、キャストを使用する必要があります。)

于 2009-06-23T08:19:04.963 に答える
0

場合によっては、どういうわけかコードが「よりクリーン」に見えるようになりますが、コードが読みにくくなることに同意します...

于 2009-06-09T19:08:19.070 に答える
0

特に複雑なジェネリック型とデリゲートの場合、コードをよりシンプルで短くすることができます。

また、変数の型を簡単に変更できます。

于 2009-06-09T19:10:03.950 に答える
0

var匿名型には不可欠です (この質問に対する以前の回答の 1 つで指摘されているように)。

私は、その長所と短所に関する他のすべての議論を「宗教戦争」として分類します. つまり、相対的なメリットの比較と議論...

var i = 5;
int j = 5;

SomeType someType = new SomeType();
var someType = new SomeType();

...完全に主観的です。

暗黙的な型付けとは、キーワードを使用して宣言された変数に実行時のペナルティがないことを意味するvarため、開発者を満足させるものについての議論になります。

于 2008-11-26T16:19:16.970 に答える
0

「私の好みについてあなたが本当に言える唯一のことは、それは時代遅れであり、やがてあなたの好みもそうなるということです。」-トールキン。

于 2010-05-19T15:10:59.143 に答える
0

間違いではありませんが、不適切な場合があります。例については、他のすべての回答を参照してください。

変数 x = 5; (悪い)

var x = 新しい SuperDooperClass(); (良い)

var x = from t in db.Something select new { Property1 = t.Field12 }; (より良い)

于 2010-05-19T15:09:12.260 に答える
0

ここでエリックの答え...

C# のジェネリック型の名前空間スコープのエイリアス

関連しています。

問題の一部は、C# に厳密に型指定されたエイリアシングがないことです。非常に多くの開発者がvarを部分サロゲートとして使用しています。

于 2010-05-19T14:51:25.303 に答える
-1

それを使用しないでください。コードが読めなくなります。

常にできるだけ厳密なタイピングを使用してください。松葉杖はあなたの人生を地獄にするだけです。

于 2010-05-19T15:05:52.623 に答える
-5

怠け者で匿名型以外に var を使用する場合は、そのような変数の命名にハンガリー語表記を使用する必要があります。

var iCounter = 0;

命!

少年、私は VB が恋しいですか。

于 2010-07-29T21:14:39.607 に答える