C # 'da var anahtar kelimesinin kullanımı

C # 3'te 'var' anahtar kelimesinin kullanımı ile ilgili meslektaşları ile görüştükten sonra insanların var yoluyla tür çıkarmanın uygun kullanımları hakkında ne düşündüklerini merak ettim.

Örneğin ben oldukça tembel şüpheli durumlarda var örneğin kullanılır: -

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'ın daha meşru kullanımları şunlardır: -

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

İlginçtir ki LINQ biraz gri bir alan gibi görünüyor, örneğin: -

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

IEnumerable'ı uygulayan bir tür olacağı sonuçların ne olacağı açıktır, ancak yeni bir nesneyi bildiren bir varlıkla aynı şekilde tamamen açık değildir.

Nesnelere LINQ söz konusu olduğunda daha da kötüdür, örneğin: -

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

Bu, equeachent foreach (someList içindeki var item) {// ...} equamentent'ten daha iyi değildir.

Burada tip güvenliği ile ilgili gerçek bir endişe var - örneğin, bu sorgunun sonuçlarını IEnumerable <int> ve IEnumerable <double> kabul eden aşırı yüklenmiş bir metoda yerleştirirsek, arayan istemeden yanlış türde geçebilir.

var yok istemeden bir yönteme türü yanlış geçerken, aşırı yükler ortalama derleyici hataları çıkarılacak olmayabilir zaman büyütülmüş bir şeyi güçlü yazarak korumak ama soru tipi tanımı hemen fark edilmeyebilir için çok tehlikeli gerçekten olup olmadığıdır.

Hala varbazı durumlarda kodu daha okunabilir hale getirebilir düşünüyorum . Bir Orders özelliği ile bir Müşteri sınıfı varsa ve bunu bir değişkene atamak istiyorsanız, ben sadece bunu yapacağım:

var orders = cust.Orders;

Müşteri.Orders olup olmadığını umursamıyorum IEnumerable<Order>, ObservableCollection<Order>ya da BindingList<Order>- tek istediğim, bu listeyi tekrarlamak ya da daha sonra bir şey elde etmek için hafızada tutmaktır.

Yukarıdaki beyanı aşağıdakilerle karşılaştırın:

ObservableCollection<Order> orders = cust.Orders;

Bana göre, tür adı sadece gürültü. Geri dönüp parça aşağı Customer.Orders türünü değiştirmeye karar Ve eğer (dan söylemek ObservableCollection<Order>için IList<Order>ben ilk RMD ediyorum eğer yapmak zorunda olmaz bir şey - o zaman ben de o bildiriyi değiştirmeye gerek) yer.

Çok kullanıyorum var. Bunun kodun okunabilirliğini azalttığı yönünde eleştiriler var, ancak bu iddiayı destekleyecek hiçbir argüman yok.

Kuşkusuz, hangi türle uğraştığımız açık değil. Ne olmuş yani? Bu aslında ayrıştırılmış bir tasarımın noktasıdır. Arayüzlerle uğraşırken, bir değişkenin sahip olduğu tiple kesinlikle ilgilenmezsiniz. varGerçek, çok öteye taşıyor, ama argüman bakış bir okunabilirliği açısından aynı kalır düşünüyorum: programcı aslında değişkenin tipinde ziyade değişken hizmet ile ilgilenen edilmemelidir yapar . Bu nedenle Microsoft, tür çıkarımını “ördek yazarak” da çağırır.

Peki, bir değişkeni kullanarak beyan ettiğimde ne yapar var? Kolay, IntelliSense bana söylediklerini yapıyor. IDE'yi görmezden gelen C # ile ilgili herhangi bir akıl gerçek değildir. Uygulamada, her C # kodu IntelliSense'i destekleyen bir IDE'de programlanmıştır.

varBildirilen bir değişken kullanıyorsam ve değişkenin ne için olduğunu karıştırırsam, kodumda temelde yanlış bir şey var. varnedeni değil, sadece semptomları görünür kılar. Elçiyi suçlama.

Şimdi, C # ekibi, yalnızca anonim bir tür oluşturan bir LINQ ifadesinin sonucunu yakalamak için kullanılması vargereken bir kodlama kılavuzu yayınladı (çünkü burada gerçek bir alternatifimiz yok ). Peki, vidala. C # ekibi bana bu kılavuz için sağlam bir argüman vermediği sürece, bunu görmezden geleceğim çünkü profesyonel ve kişisel düşünceme göre, bu tamamen baloney. (Üzgünüm; söz konusu yönerge ile ilgili bir bağlantım yok.)var

Aslında, neden kullanmamanız gerektiğine dair bazı (yüzeysel) iyi açıklamalar var varama yine de büyük ölçüde yanlış olduklarına inanıyorum. “Aranabilirlik” örneğini ele alalım: yazar , kullanılan varyerleri aramayı zorlaştırdığını iddia ediyor MyType. Sağ. Arayüzler de öyle. Aslında, neden sınıfın nerede kullanıldığını bilmek isteyeyim? Nerede başlatıldığıyla daha fazla ilgilenebilirim ve bu hala aranabilir olacaktır çünkü kurucusunun bir yere çağrılması gerekir (bu dolaylı olarak yapılsa bile, tür adı bir yerde belirtilmelidir).

Var, bence, C # iyi bir şey ^tm . Bu şekilde yazılan herhangi bir değişken hala güçlü bir şekilde yazılır, ancak türünü, tanımlandığı ödevin sağ tarafından alır. Tür bilgileri sağ tarafta bulunduğundan, çoğu durumda, sol tarafa da girilmesi gereksiz ve aşırı ayrıntılıdır. Bunun tip güvenliğini azaltmadan okunabilirliği önemli ölçüde artırdığını düşünüyorum.

Benim açımdan, değişkenler ve yöntemler için iyi adlandırma kuralları kullanmak, okunabilirlik açısından açık tip bilgiden daha önemlidir. Tip bilgisine ihtiyacım varsa, her zaman değişkenin (VS'de) üzerine gelip alabilirim. Bununla birlikte, genellikle, okuyucu için açık tip bilgi gerekli olmamalıdır. Geliştirici için, VS'de değişkenin nasıl bildirildiğine bakılmaksızın hala Intellisense alırsınız. Tüm bunları söyledikten sonra, türü açıkça bildirmenin mantıklı olduğu durumlar olabilir - belki de a döndüren bir yönteminiz vardır List<T>, ancak bunu birIEnumerable<T>yönteminizde. Arabirimi kullandığınızdan emin olmak için arabirim türünün değişkenini bildirmek bunu açık hale getirebilir. Ya da, belki de, başlangıç ​​değeri olmayan bir değişkeni bildirmek istersiniz - çünkü hemen bazı koşullara dayalı bir değer alır. Bu durumda tipe ihtiyacınız vardır. Tür bilgisi yararlı veya gerekliyse, devam edin ve kullanın. Yine de, genellikle gerekli olmadığını ve kod çoğu durumda onsuz okumak daha kolay olduğunu hissediyorum.

Bunların hiçbiri kesinlikle doğru değil; varokunabilirlik üzerinde olumlu ve olumsuz etkileri olabilir. Bence, varaşağıdakilerden biri doğru olduğunda kullanılmalıdır:

1. Tür anonimdir ( bu durumda var olması gerektiği için burada başka seçeneğiniz yoktur )
2. Tipi tayin tanımlanması üzerine belirgin dayanır (örneğin var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

varsözdizimsel şeker olduğu için hiçbir performans etkisi yoktur; derleyici tipe girer ve IL'ye derlendiğinde onu tanımlar; bu konuda gerçekten dinamik bir şey yok.

C # ekibinde Kıdemli Yazılım Tasarım Mühendisi Eric Lippert'den:

varAnahtar kelime neden tanıtıldı?

Biri bugün var, biri 3.0'da ortaya çıkacak iki neden var.

İlk neden, bu kodun tüm fazlalık nedeniyle inanılmaz derecede çirkin olması:

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

Ve bu basit bir örnek - daha kötü yazdım. Aynı şeyi iki kez yazmak zorunda kaldığınızda, kaldırabileceğimiz bir artıklık budur. Yazmak çok daha hoş

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

ve derleyiciye ödeve dayalı türün ne olduğunu bulmasına izin verin.

İkincisi, C # 3.0, anonim türler sunar. Tanıma göre anonim türlerin adı olmadığından, türü anonim ise, değişkenin türünü başlangıç ​​ifadesinden çıkarabilmeniz gerekir .

Vurgu madeni. Bütün makale, C # 3.0 hala statik olarak yazılmış, dürüst! ve takip eden dizi oldukça iyi.

Bunun variçin bu. Diğer kullanımlar muhtemelen çok iyi çalışmayacaktır. JScript, VBScript veya dinamik yazarak yapılan herhangi bir karşılaştırma toplam ranzadır. Not yine varedilir gerekli .NET içinde diğer bazı özellikleri iş var için.

Ben var kullanımı akıllıca seçilmiş değişken isimleri ile birleştirilmesi gerektiğini düşünüyorum.

Ben böyle olmadığı sürece bir foreach ifadesinde var kullanarak hiçbir sorun yok:

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

Daha çok böyle olsaydı:

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

... sonra kodu okuyan birisinin "liste" nin ne olduğunu anlama olasılığı daha yüksektir. Liste değişkeninin adı üzerinde kontrolünüz varsa, bu daha da iyidir.

Aynı durum diğer durumlar için de geçerlidir. Bu oldukça işe yaramaz:

var x = SaveFoo(foo);

... ama bu mantıklı:

var saveSucceeded = SaveFoo(foo);

Her biri kendi başına, sanırım. Kendimi bunu yaparken buldum, ki bu sadece çılgınca:

var f = (float)3;

Bir çeşit 12 adımlı var programına ihtiyacım var. Benim adım Matt ve ben (ab) var.

Bakım modunda yeni geliştirmeden çok daha fazla zaman harcadığınız varsayımına dayanarak "makineler değil insanlar için kodlar" ahlakını kabul ettik.

Benim için bu, derleyicinin değişkenin ne tür olduğunu "bildiğini" argümanı geçersiz kılar - elbette, derleyici kodunuzun derlenmesini durdurduğundan, ancak bir sonraki geliştirici kodu okurken ilk kez geçersiz kod yazamazsınız 6 ay içinde değişkenin ne yaptığını doğru ya da yanlış yaptığını ve sorunların nedenini hızlı bir şekilde belirleyebilmeleri gerekir.

Böylece,

var something = SomeMethod();

kodlama standartlarımız tarafından yasaklanmıştır, ancak okunabilirliği arttırdığı için ekibimizde aşağıdakiler teşvik edilmektedir:

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

Kötü değil, daha sübjektif olma eğilimi olan daha stilistik bir şey. Var kullandığınızda ve kullanmadığınızda tutarsızlıklar ekleyebilir.

Başka bir endişe konusu, aşağıdaki çağrıda sadece döndürülen koda bakarak söyleyemezsiniz CallMe:

var variable = CallMe();

Bu var karşı ana şikayet.

Metodlarda anonim delegeler ilan ettiğimde var kullanıyorum, bir şekilde var kullanacağımdan daha temiz görünüyor Func. Bu kodu düşünün:

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

EDIT : Julian'ın girdisine dayalı olarak son kod örneği güncellendi

Var hiç de varyant gibi değil. Değişken hala güçlü bir şekilde yazılmıştır, sadece bu şekilde elde etmek için tuşlara basmamanızdır. Türü görmek için fareyle üzerine gelebilirsiniz. Basılı kodu okuyorsanız, türün ne olduğunu anlamak için biraz düşünmeniz gerekebilir. Ancak onu bildiren tek bir satır ve onu kullanan birçok satır vardır, bu yüzden şeylere iyi adlar vermek, kodunuzu daha kolay takip etmenin en iyi yoludur.

Intellisense kullanmak tembel midir? Tüm addan daha az yazıyor. Yoksa daha az iş ama eleştiriyi hak etmeyen şeyler var mı? Bence var ve var onlardan biri.

Buna ihtiyaç duyacağınız en muhtemel zaman anonim türler içindir (% 100 gerekli olduğu yerde); ancak önemsiz durumlar için tekrardan kaçınır ve IMO hattı daha net hale getirir. Basit bir başlatma için türü iki kez görmem gerekmiyor.

Örneğin:

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

(lütfen yukarıdaki hscroll düzenlemeyin - bu biraz kanıtlıyor !!!)

vs:

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

Bununla birlikte, bunun yanıltıcı olduğu ve potansiyel olarak hatalara neden olabileceği durumlar vardır. varOrijinal değişken ve başlatılmış tür aynı değilse kullanmaya dikkat edin . Örneğin:

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'ın zor olduğu özel bir durum: çevrimdışı kod incelemeleri, özellikle kağıt üzerinde yapılanlar.

Bunun için fareyle üzerine gelemezsiniz.

Büyük anlaşmanın ne olduğunu anlamıyorum ..

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

Hala 'bir şey' konusunda tam bir fikre sahipsiniz ve belirsiz bir durum için birim testleriniz var, değil mi? ( yapıyor musun? )

Varchar değil, loş değil ve kesinlikle dinamik veya zayıf yazım değil. Bu maddnes'i şu şekilde durduruyor:

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

ve toplam zihin karmaşasını azaltmak:

var v = new List<somethinglongtypename>();

Güzel, o kadar güzel değil:

v = List<somethinglongtypename>();

Ama sonra Boo bunun için.

Birisi var"türü bulmak" istemediği için anahtar kelimeyi kullanıyorsa , bu kesinlikle yanlış nedendir. varDinamik bir türüne sahip bir değişken oluşturmak değil anahtar, derleyici hala türü bilmek zorunda değil. Değişkenin her zaman belirli bir türü olduğundan, türün mümkünse kodda da belirgin olması gerekir.

varAnahtar kelimeyi kullanmanız için iyi nedenler şunlardır:

• Gerektiğinde, yani anonim tip için bir referans beyan etmek.
• Kodu daha okunabilir kıldığı yerde, yani tekrarlayan bildirimleri kaldırmak.

Veri türünü yazmak genellikle kodun izlenmesini kolaylaştırır. Hangi veri türlerini kullandığınızı gösterir, böylece önce kodun ne yaptığını anlayarak veri türünü bulmak zorunda kalmazsınız.

Intellisense'ın şu anda ne kadar güçlü olduğu göz önüne alındığında, var'ın bir sınıfta üye değişkenlere veya görünür ekran alanında tanımlanan bir yöntemde yerel değişkenlere sahip olmaktan daha zor olduğunu bilmiyorum.

Gibi bir kod satırınız varsa

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

Okunması çok daha kolay veya zor:

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

Ben VAR ile anahtar şey sadece uygun yerlerde kullanmak olduğunu yani Linq kolaylaştırır (ve muhtemelen diğer durumlarda) bir şeyler yaparken.

Eğer ettiyseniz var içinde bir şey için bir tür o zaman kullanmalıyım - yapmamaya böylece genel teşvik edilmelidir yaratıcı tembellik aksine basit tembellik (- iyi programcılar oft tembel olmaya çok çalışıyoruz ve düşünülebilir ilk etapta şeyin kaynağı).

Battaniye yasağı, yapıyı kötüye kullanmak kadar kötüdür, ancak mantıklı bir kodlama standardına ihtiyaç vardır.

Hatırlanması gereken diğer şey, türlerini değiştirmek olamayacağını onun değil bir VB tipi var - o olduğunu kesinlikle yazılı değişken onun tipi (anlaşılmaktadır sadece hangi onun mantıksız değil olduğunu iddia edecektir insanlar vardır yüzden diyelim ki bir foreach kullanıyorum ama hem okunabilirlik hem de sürdürülebilirlik nedenlerinden dolayı katılmıyorum).

Bu çalışacak ve koşacak şüpheli (-:

Murph

Tabii, intkolaydır, ancak değişkenin türü olduğunda IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var işleri daha kolay hale getirir.

Çalıntı CodingHorror bu konuda yazı :

Ne yazık ki, siz ve diğer herkes hemen hemen yanlış anladınız. Artıklığın iyi bir şey olmadığını kabul etsem de, bu sorunu çözmenin en iyi yolu aşağıdaki gibi bir şey yapmak olurdu:

Nicholas Paldino .NET / C # MVP, 20 Haziran 2008 08:00 AM

Sanırım asıl endişeniz daha az yazmak zorundaysa - o zaman onu kullanmanıza engel olacak herhangi bir argüman yoktur.

Yalnızca yapacaksanız hiç , sonra koduna kim umurunda bakar insan olmak? Aksi takdirde, böyle bir durumda:

var people = Managers.People

iyi, ama böyle bir durumda:

var fc = Factory.Run();

beynimin kodun İngilizce'sinden oluşmaya başlayabileceği herhangi bir acil tip kesintisini kısa devre yapar.

Aksi takdirde, projeniz üzerinde çalışması gerekebilecek diğer kişilere karşı en iyi muhakemenizi ve programlama 'nezaketinizi' kullanın.

Kullanılması varyerine açık Çeşidi refactorings çok daha kolay (bu nedenle hiçbir fark yarattı yoksa sadece "sözdizimsel şeker" demek önceki afişleri ters olmalıdır) yapar.

Bu yöntemin çağrıldığı her dosyayı değiştirmeden yöntemlerinizin dönüş türünü değiştirebilirsiniz. Hayal etmek

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

hangi gibi kullanılır

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

Bir SomeMethod()döndürmek için yeniden düzenleme yapmak IEnumerable<MySecondClass>isterseniz, değişken bildirimini değiştirmeniz gerekir (ayrıcaforeach istiyorsanız, yöntemi kullandığınız her yerde ) .

Yazarsan

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

bunun yerine, değiştirmeniz gerekmez.

@aku: Bir örnek kod incelemeleridir. Başka bir örnek, yeniden düzenleme senaryolarıdır.

Temelde faremle tip avına çıkmak istemiyorum. Kullanılamayabilir.

Bu bir zevk meselesi. Hakkında tüm bu hilkat garibesiDinamik olarak yazılan dillere alıştığınızda bir değişkenin türü ortadan kalkar. Yani, eğer onları sevmeye başlarsanız (herkesin yapabileceğinden emin değilim, ama yaparım).

C # 's varoldukça serin dinamik yazım gibi görünüyor , ama aslında statik yazım - derleyici doğru kullanımı zorlar.

Değişkeninizin türü gerçekten o kadar önemli değil (daha önce söylendi). Bağlamdan (diğer değişkenler ve yöntemlerle etkileşimleri) ve adından nispeten açık olmalıdır - beklemeyin customerList'in bir int...

Hala patronumun bu konuda ne düşündüğünü görmeyi bekliyorum - 3.5'te yeni yapıları kullanmak için "devam et" battaniyem var, ama bakım hakkında ne yapacağız?

Arasında karşılaştırıldığında IEnumerable<int>ve IEnumerable<double>size endişe gerekmez - Eğer kod zaten derlemek olmaz türü yanlış geçirirseniz.

Olarak tip-güvenliği konusunda hiçbir endişe var, varbir değil dinamik. Bu sadece derleyici büyüsü ve yaptığınız her tür güvensiz arama yakalanacak.

Var Linq için kesinlikle gereklidir:

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

Şimdi anonEnumeration'a intellisense bakın ve böyle bir şey görünecekIEnumerable<'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 # derleyicisi oldukça zekidir - ayrı ayrı üretilen anon türleri, özellikleri eşleşirse aynı tür üretilir.

Bunun dışında, bilginiz olduğu sürece var, bağlamın net olduğu her yerde kullanmak mantıklıdır .

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

Sanırım bakış açınıza bağlı. Şahsen var"yanlış kullanım" nedeniyle bir kod parçasını anlamakta hiç zorluk çekmedim ve iş arkadaşlarım ve ben bunu oldukça fazla kullanıyorum. (Intellisense'in bu konuda büyük bir yardım olduğuna katılıyorum.) Tekrarlı rüzgarı kaldırmanın bir yolu olarak kabul ediyorum.

Sonuçta, eğer gibi ifadeler

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

başa çıkmak gerçekten imkansızdı, kimse dinamik olarak yazılmış dilleri kullanmazdı.

Sadece hangi türün kullanıldığını görmek net olduğunda var kullanıyorum.

Örneğin, x'in "Sınıfım" türünde olacağını hemen görebileceğiniz için bu durumda var kullanacağım:

var x = new MyClass();

Fareyi kodun üzerine sürükleyip MyFunction'un ne tür döndüğünü görmek için araç ipucuna bakmanız gerektiğinden, böyle durumlarda KULLANMAYACAĞIM:

var x = MyClass.MyFunction();

Özellikle, sağ tarafın bir yöntem değil, sadece bir değer olduğu durumlarda asla var kullanmıyorum:

var x = 5;

(çünkü derleyici bayt, kısa, int veya başka bir şey isteyip istemediğimi bilemez)

Bana göre antipati var, .NET'te iki dilliliğin neden önemli olduğunu göstermektedir. Ayrıca VB .NET yapmış olan C # programcıları için avantajları varsezgisel olarak açıktır. Standart C # beyanı:

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

VB .NET'te şunu yazmanın karşılığıdır:

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

Kimse VB .NET'te bunu yapmaz. Aptalca olurdu, çünkü .NET'in ilk sürümünden beri bunu başardınız ...

Dim whatever As New List(Of String)

... bu da değişkeni yaratır ve hepsini oldukça küçük bir satırda başlatır. Ah, ama ne istiyorsan IList<string>, değil List<string>mi? Peki, VB. NET'te bunu yapmanız gerektiği anlamına gelir:

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

Tıpkı C # 'da yapmak zorunda kalacağınız ve açıkçası kullanamadığınız vargibi:

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

Eğer varsa gerek farklı bir şey olması türünü, bu olabilir. Ancak iyi programlamanın temel ilkelerinden biri artıklığı azaltmaktır ve var tam da bunu yapar.

Anonim türler için kullanın - bunun için var. Başka bir şey çok uzak bir kullanımdır. C'de yetişen birçok insan gibi ben de bu tipin bildirisinin soluna bakmaya alışkınım. Zorunlu olmadıkça sağ tarafa bakmıyorum. varHerhangi bir eski deklarasyon için kullanmak beni her zaman yapmamı sağlıyor, ki bu şahsen rahatsız edici buluyorum.

'Önemli değil, mutlu olduğun şeyi kullan' diyenler resmin tamamını görmezler. Herkes bir noktada başka insanların kodlarını alacak ve yazdıkları sırada verdikleri kararlarla uğraşmak zorunda kalacak. Tüm ' varya da değil' şeyi karışıma eklemeden radikal olarak farklı adlandırma kurallarıyla ya da - klasik kavrama - canlandırıcı stillerle uğraşmak yeterince kötü . En kötü durum, bir programcının kullanmadığı varve daha sonra onu seven ve onu kullanarak kodu genişleten bir bakımcı geleceği olacaktır. Şimdi kutsal olmayan bir karışıklığın var.

Standartlar tam olarak iyi bir şeydir, çünkü rastgele kod alıp hızlı bir şekilde almanız çok daha olasıdır. Ne kadar farklı olursa o kadar zorlaşır. Ve 'her yerde var' stiline geçmek büyük bir fark yaratıyor.

Dinamik yazmayı umursamıyorum ve onlar için tasarlanmış dillerde yazmayı da taklit etmiyorum. Python'u çok seviyorum. Ancak C #, statik olarak açıkça yazılan bir dil olarak tasarlanmıştır ve bu şekilde kalmalıdır. Anonim türler için kurallara uymak yeterince kötüydü; İnsanların bunu daha da ileri götürmelerine ve dilin deyimlerini daha da kırmasına izin vermek, memnun olmadığım bir şey. Şimdi cin şişeden çıktı, asla geri dönmeyecek. C # kamplara balkanlaştırılacak. İyi değil.

Test sırasında birçok zaman, kendimi böyle bir kod sahip buluyorum:

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

Şimdi, bazen, SomeOtherThing'in kendisinin ne içerdiğini görmek isteyeceğim, SomeOtherThing, CallMethod () öğesinin döndürdüğü türle aynı değildir. Ben var olsa kullandığım için, ben sadece bunu değiştirmek:

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

buna:

var something = myObject.SomeProperty.SomeOtherThing;

Var olmadan, sol tarafta da bildirilen türü değiştirmeye devam etmeliydim. Küçük olduğunu biliyorum, ama son derece uygun.

varZaman kazandıran düşünceler için , yazmak için daha az tuş vuruşu gerekir:

StringBuilder sb = new StringBuilder();

göre

var sb = new StringBuilder();

Bana inanmıyorsan onları say ...

19 ve 21

Gerekirse açıklayacağım, ama sadece deneyin ... (zekanızın mevcut durumuna bağlı olarak her biri için birkaç tane daha yazmanız gerekebilir)

Ve aklınıza gelebilecek her tip için doğrudur !!

Benim kişisel hissim, varlığın asla bilinmediği durumlar dışında kullanılmaması gerektiğidir, çünkü koddaki tanıma okunabilirliğini azaltır. Beynin türü tanıması tam bir çizgiden daha uzun sürer. Makine kodunu ve bitlerini anlayan eski zamanlayıcılar tam olarak neden bahsettiğimi biliyor. Beyin paralel olarak işler ve var kullandığınızda onu seri hale getirmeye zorlarsınız. Neden birisi beyninin daha fazla çalışmasını ister ki? Bilgisayarlar bunun için.

Tüm yerleri üzerinde ben bölünmüş var, benim için tek şüpheli yerleri dahili kısa türleridir, mesela ben tercih int i = 3;üzerindevar i = 3;

Dün yazdığım koddan işleri basitleştirebiliriz:

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

Bu olmadan son derece ayrıntılı olurdu var.

Zeyilname: Gerçek tür çıkarımlı bir dil (örn. F #) ile harcanan biraz zaman, derleyicilerin ifade türlerini doğru bir şekilde elde etme konusunda ne kadar başarılı olduklarını gösterecektir. Kesinlikle elimden geldiğince kullanmaya eğilimli olduğum anlamına geliyordu varve şimdi açık bir tür kullanmak, değişkenin başlangıç ​​ifadesinin türünden olmadığını gösteriyor.

Hiçbiri, ancak tür adını iki kez yazmak zorunda değilsiniz. http://msdn.microsoft.com/en-us/library/bb383973.aspx