Użycie słowa kluczowego var w C #

Po dyskusji z kolegami na temat użycia słowa kluczowego „var” w C # 3 zastanawiałem się, jakie są opinie ludzi na temat właściwego zastosowania wnioskowania typu przez var?

Na przykład dość leniwie używałem var w wątpliwych okolicznościach, np .:

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.

Bardziej uzasadnione użycie var jest następujące:

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

Co ciekawe, LINQ wydaje się być trochę szarym obszarem, np .:

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

Jest oczywiste, jakie będą wyniki, ponieważ będzie to typ, który implementuje IEnumerable, jednak nie jest to całkowicie oczywiste w taki sam sposób, jak var deklarujący nowy obiekt.

Jest jeszcze gorzej, jeśli chodzi o LINQ do obiektów, np .:

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

Nie jest to lepsze niż równoważnik foreach (var item in someList) {// ...} ekwiwalent.

Istnieje poważna obawa o bezpieczeństwo typu - na przykład, gdybyśmy umieścili wyniki tego zapytania w przeciążonej metodzie, która zaakceptowała IEnumerable <int> i IEnumerable <double>, osoba dzwoniąca mogłaby przypadkowo przekazać niewłaściwy typ.

var ma utrzymać silną wpisywanie ale pytanie jest naprawdę, czy jest to niebezpieczne dla typu, aby nie być od razu widoczne na definicji, coś, co jest powiększony przy przeciążeniach średnie błędy kompilatora nie może być wydane, gdy nieumyślnie przekazać niewłaściwy typ sposobu.

Nadal uważam, varże w niektórych przypadkach kod może być bardziej czytelny. Jeśli mam klasę Customer z właściwością Orders i chcę przypisać ją do zmiennej, po prostu zrobię to:

var orders = cust.Orders;

Nie obchodzi mnie, czy Customer.Orders jest IEnumerable<Order>, ObservableCollection<Order>czyBindingList<Order> - wszystko, czego chcę, to zachować tę listę w pamięci, aby iterować nad nią lub uzyskać jej liczbę lub coś później.

Porównaj powyższą deklarację z:

ObservableCollection<Order> orders = cust.Orders;

Dla mnie nazwa typu to po prostu hałas. A jeśli wrócę i zdecyduję się zmienić typ klienta. Zamówienia w dół ścieżki (powiedzmy od ObservableCollection<Order>do IList<Order>) to muszę również zmienić tę deklarację - coś, czego nie musiałbym zrobić, gdybym użył var w pierwszym miejsce.

używam var intensywnie. Pojawiła się krytyka, że ​​zmniejsza to czytelność kodu, ale nie ma argumentu na poparcie tego twierdzenia.

Wprawdzie może to oznaczać, że nie jest jasne, z jakim typem mamy do czynienia. Więc co? To jest właściwie cel oddzielonego projektu. Podczas pracy z interfejsami zdecydowanie nie interesuje Cię typ zmiennej. varidzie to o wiele dalej, prawda, ale myślę, że argument pozostaje taki sam z punktu widzenia czytelności: programista nie powinien być zainteresowany typem zmiennej, ale raczej tym, co robi zmienna . Właśnie dlatego Microsoft nazywa również wnioskowanie typu „pisanie kaczką”.

Co więc robi zmienna, kiedy ją deklaruję var? Łatwo, robi to, co mówi mi IntelliSense. Wszelkie rozumowania dotyczące C #, które ignorują IDE, nie są realne. W praktyce każdy kod C # jest programowany w środowisku IDE obsługującym IntelliSense.

Jeśli używam varzadeklarowanej zmiennej i mylę się, po co jest zmienna, w moim kodzie jest coś zasadniczo nie tak. varnie jest przyczyną, powoduje jedynie, że objawy są widoczne. Nie obwiniaj posłańca.

Teraz zespół C # wydał wytyczne dotyczące kodowania, które varpowinny być używane tylko do przechwytywania wyniku instrukcji LINQ, która tworzy typ anonimowy (ponieważ tutaj nie mamy prawdziwej alternatywy var). Cóż, pieprzyć to. Dopóki zespół C # nie da mi solidnego argumentu za tą wytyczną, będę ją ignorować, ponieważ moim profesjonalnym i osobistym zdaniem jest to czysty baloney. (Przepraszam; nie mam linku do omawianych wytycznych.)

W rzeczywistości istnieją pewne (powierzchownie) dobre wyjaśnienia, dlaczego nie powinieneś używać, varale nadal uważam, że są w dużej mierze błędne. Weźmy przykład „wyszukiwalności”: autor twierdzi, że varutrudnia to wyszukiwanie miejsc, w których MyTypejest używany. Dobrze. Podobnie jak interfejsy. Właściwie dlaczego miałbym chcieć wiedzieć, gdzie jest używana klasa? Mógłbym być bardziej zainteresowany tym, gdzie jest on tworzony, a to nadal będzie możliwe do przeszukiwania, ponieważ gdzieś trzeba wywołać jego konstruktor (nawet jeśli jest to zrobione pośrednio, należy podać gdzieś nazwę typu).

Var, moim zdaniem, w C # jest rzeczą dobrą ^tm . Każda tak wpisana zmienna jest nadal silnie wpisana, ale pobiera swój typ z prawej strony przypisania, w którym jest zdefiniowana. Ponieważ informacje o typie są dostępne po prawej stronie, w większości przypadków niepotrzebne i nadmiernie gadatliwe jest również wprowadzanie ich po lewej stronie. Myślę, że to znacznie zwiększa czytelność bez zmniejszania bezpieczeństwa typu.

Z mojego punktu widzenia stosowanie dobrych konwencji nazewnictwa dla zmiennych i metod jest ważniejsze z punktu widzenia czytelności niż wyraźne informacje o typie. Jeśli potrzebuję informacji o typie, zawsze mogę najechać wskaźnikiem na zmienną (w VS) i uzyskać ją. Zasadniczo jednak czytelne informacje o typie nie powinny być konieczne. Dla programisty w VS nadal otrzymujesz Intellisense, niezależnie od tego, jak deklarowana jest zmienna. Powiedziawszy to wszystko, mogą nadal występować przypadki, w których sensowne jest jawne zadeklarowanie typu - być może masz metodę, która zwracaList<T> , ale chcesz traktować ją jakoIEnumerable<T>w twojej metodzie. Aby upewnić się, że korzystasz z interfejsu, zadeklarowanie zmiennej typu interfejsu może to wyraźnie wyjaśnić. A może chcesz zadeklarować zmienną bez wartości początkowej - ponieważ natychmiast otrzymuje wartość na podstawie pewnego warunku. W takim przypadku potrzebujesz tego typu. Jeśli informacje o typie są przydatne lub konieczne, skorzystaj z nich. Wydaje mi się jednak, że zazwyczaj nie jest to konieczne, a kod jest łatwiejszy do odczytania bez niego w większości przypadków.

Żadne z nich nie jest absolutnie prawdziwe; varmoże mieć zarówno pozytywny, jak i negatywny wpływ na czytelność. Moim zdaniem varpowinien być stosowany, gdy spełniony jest jeden z poniższych warunków:

1. Typ jest anonimowy (cóż, tutaj nie masz wyboru, ponieważ w tym przypadku musi być zmienny)
2. Typ jest oczywisty na podstawie przypisanego wyrażenia (tj. var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

varnie ma wpływu na wydajność, ponieważ jest cukrem syntaktycznym; kompilator określa typ i definiuje go po skompilowaniu do IL; nic faktycznie dynamiczny o nim.

Eric Lippert, starszy inżynier oprogramowania w zespole C #:

Dlaczego varwprowadzono słowo kluczowe?

Istnieją dwa powody, jeden istniejący dzisiaj, jeden, który pojawi się w wersji 3.0.

Pierwszym powodem jest to, że ten kod jest niesamowicie brzydki z powodu całej nadmiarowości:

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

I to jest prosty przykład - napisałem gorzej. Za każdym razem, gdy będziesz zmuszony wpisać dokładnie to samo dwa razy, możemy usunąć nadmiarowość. O wiele ładniej pisać

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

i pozwól kompilatorowi dowiedzieć się, jaki typ jest oparty na przypisaniu.

Po drugie, C # 3.0 wprowadza anonimowe typy. Ponieważ typy anonimowe z definicji nie mają nazw, musisz być w stanie wywnioskować typ zmiennej z wyrażenia inicjującego, jeśli jej typ jest anonimowy.

Podkreśl moje. Cały artykuł, C # 3.0 jest wciąż statycznie wpisany, szczerze! , a kolejne serie są całkiem dobre.

Po to varjest. Inne zastosowania prawdopodobnie nie będą działać tak dobrze. Każde porównanie z JScript, VBScript lub pisaniem dynamicznym jest całkowitą koją. Uwaga: varjest wymagana , aby niektóre inne funkcje działały w .NET.

Myślę, że użycie var powinno być połączone z mądrze wybranymi nazwami zmiennych.

Nie mam problemu z użyciem var w instrukcji foreach, pod warunkiem, że nie jest tak:

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

Gdyby było mniej więcej tak:

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

... wtedy ktoś czytający kod znacznie chętniej zrozumie, czym jest „lista”. Jeśli masz kontrolę nad nazwą samej zmiennej listy, to nawet lepiej.

To samo może dotyczyć innych sytuacji. Jest to dość bezużyteczne:

var x = SaveFoo(foo);

... ale to ma sens:

var saveSucceeded = SaveFoo(foo);

Chyba każdy na swój. Przekonałem się, że robię to, co jest po prostu szalone:

var f = (float)3;

Potrzebuję 12-etapowego programu var. Nazywam się Matt i ja (ab) używam var.

Przyjęliśmy etos „Kod dla ludzi, a nie maszyn”, oparty na założeniu, że spędzasz wiele razy więcej w trybie konserwacji niż na nowym rozwoju.

Dla mnie wyklucza to argument, że kompilator „wie”, jakiego typu jest zmienna - na pewno nie możesz napisać niepoprawnego kodu za pierwszym razem, ponieważ kompilator zatrzymuje kompilowanie kodu, ale gdy następny programista czyta kod w ciągu 6 miesięcy muszą być w stanie wywnioskować, co robi zmienna poprawnie lub niepoprawnie, i szybko zidentyfikować przyczynę problemów.

A zatem,

var something = SomeMethod();

jest zabronione przez nasze standardy kodowania, ale nasz zespół zachęca do następujących działań, ponieważ zwiększa to czytelność:

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

Nie jest źle, to bardziej stylistyczna rzecz, która wydaje się być subiektywna. Może dodawać niespójności, kiedy używasz var, a kiedy nie.

Kolejny niepokojący przypadek: w poniższym wywołaniu nie można po prostu spojrzeć na kod zwracany przez typ CallMe:

var variable = CallMe();

To moja główna skarga przeciwko var.

Używam var, kiedy deklaruję anonimowych delegatów metodami, jakoś var wygląda na czystsze niż gdybym używał Func. Rozważ ten kod:

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

EDYCJA : Zaktualizowałem ostatnią próbkę kodu na podstawie danych wejściowych Juliana

Var wcale nie jest jak wariant. Zmienna jest nadal silnie wpisana, po prostu nie naciskasz klawiszy, aby uzyskać ją w ten sposób. Możesz najechać na niego kursorem w Visual Studio, aby zobaczyć typ. Jeśli czytasz drukowany kod, być może będziesz musiał pomyśleć, aby dowiedzieć się, jaki jest typ. Ale jest tylko jedna linia, która go deklaruje, i wiele linii, które go używają, więc nadawanie rzeczom przyzwoitych nazw jest nadal najlepszym sposobem na ułatwienie śledzenia kodu.

Czy używanie Intellisense jest leniwe? To mniej pisania niż całe imię. Czy są rzeczy, które są mniej pracy, ale nie zasługują na krytykę? Myślę, że są, a var jest jednym z nich.

Najbardziej prawdopodobny czas, jaki będziesz tego potrzebować, dotyczy typów anonimowych (gdy jest to wymagane w 100%); ale pozwala również uniknąć powtórzeń w trywialnych przypadkach, a IMO czyni linię wyraźniejszą. Nie muszę widzieć tego typu dwukrotnie w celu prostej inicjalizacji.

Na przykład:

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

(proszę nie edytować hscroll powyżej - to trochę potwierdza sens !!!)

vs:

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

Są jednak sytuacje, w których jest to mylące i może potencjalnie powodować błędy. Zachowaj ostrożność, varjeśli oryginalna zmienna i typ inicjowany nie były identyczne. Na przykład:

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

Jeden szczególny przypadek, w którym var jest trudny: przeglądy kodu offline, zwłaszcza te wykonane na papierze.

Nie możesz w tym celu polegać na najechaniu myszką.

Nie rozumiem o co chodzi ...

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

Nadal masz pełną inteligencję na „czymś”, aw każdym niejednoznacznym przypadku masz testy jednostkowe, prawda? ( czy ty? )

To nie jest varchar, nie jest słabe, a na pewno nie jest dynamiczne ani słabe pisanie. To powstrzymuje Maddnesa w ten sposób:

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

i redukując ten totalny bałagan do:

var v = new List<somethinglongtypename>();

Fajnie, nie tak ładnie jak:

v = List<somethinglongtypename>();

Ale do tego właśnie służy Boo .

Jeśli ktoś używa varsłowa kluczowego, ponieważ nie chce „ustalić typu”, jest to zdecydowanie zły powód. Słowo varkluczowe nie tworzy zmiennej o typie dynamicznym, kompilator nadal musi znać ten typ. Ponieważ zmienna zawsze ma określony typ, typ powinien być również widoczny w kodzie, jeśli to możliwe.

Dobrym powodem do użycia tego varsłowa kluczowego są na przykład:

• Tam, gdzie jest to potrzebne, tj. Do zadeklarowania referencji dla anonimowego typu.
• Gdzie sprawia, że ​​kod jest bardziej czytelny, tzn. Usuwa powtarzające się deklaracje.

Zapisanie typu danych często ułatwia śledzenie kodu. Pokazuje typy danych, których używasz, abyś nie musiał rozgryzać typu danych, najpierw zastanawiając się, co robi kod.

Biorąc pod uwagę, jak potężna jest teraz Intellisense, nie jestem pewien, czy var jest trudniejszy do odczytania niż posiadanie zmiennych składowych w klasie lub zmiennych lokalnych w metodzie zdefiniowanej poza widocznym obszarem ekranu.

Jeśli masz wiersz kodu, taki jak

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

Jest o wiele łatwiejszy lub trudniejszy do odczytania niż:

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

Myślę, że kluczową rzeczą w VAR jest używanie go tylko tam, gdzie jest to właściwe, tj. Podczas robienia rzeczy w Linq, które to ułatwia (i prawdopodobnie w innych przypadkach).

Jeśli masz typ czegoś w czym należy go używać - nie do tego jest prosty lenistwo (w przeciwieństwie do twórczego lenistwa, które jest ogólnie zachęcać - dobra programiści często pracują bardzo ciężko, aby być leniwy i mogą być uznane źródło rzeczy w pierwszej kolejności).

Całkowity zakaz jest tak samo zły jak nadużywanie konstruktu, ale musi istnieć rozsądny standard kodowania.

Inną rzeczą do zapamiętania jest to, że nie jest to zmienna typu VB, ponieważ nie może zmieniać typów - jest to zmienna o silnym typie, po prostu wnioskuje o typie (dlatego są ludzie, którzy twierdzą, że nie jest nierozsądne użyj go, powiedzmy, w foreach, ale nie zgodzę się ze względu zarówno na czytelność, jak i konserwację).

Podejrzewam, że ten będzie działać i działać (-:

Murph

Jasne, intjest łatwe, ale gdy typem zmiennej jest IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var znacznie ułatwia.

Skradzione z postu na ten temat w CodingHorror :

Niestety, ty i wszyscy inni źle to zrozumieliście. Chociaż zgadzam się z tobą, że redundancja nie jest dobrą rzeczą, lepszym sposobem rozwiązania tego problemu byłoby zrobienie czegoś takiego:

Nicholas Paldino .NET / C # MVP w dniu 20 czerwca 2008 08:00

Sądzę, że jeśli Twoim głównym zmartwieniem jest pisanie mniej - nie ma żadnego argumentu, który mógłby cię zniechęcić do korzystania z niego.

Jeśli kiedykolwiek będziesz tylko osobą, która patrzy na twój kod, to kogo to obchodzi? W przeciwnym razie, w takim przypadku:

var people = Managers.People

jest w porządku, ale w takim przypadku:

var fc = Factory.Run();

powoduje zwarcie wszelkich natychmiastowych dedukcji typu, które mój mózg mógłby zacząć formować z „angielskiego” kodu.

W przeciwnym razie skorzystaj z najlepszej oceny i zaprogramuj „uprzejmość” w stosunku do innych osób, które mogą być zmuszone do pracy nad Twoim projektem.

Za pomocą var zamiast wyraźnego typu znacznie ułatwia refaktoryzację (dlatego muszę zaprzeczyć poprzednim plakatom, które oznaczały, że nie robiło to różnicy lub że był to wyłącznie „cukier składniowy”).

Możesz zmienić typ zwracanych metod bez zmiany każdego pliku, w którym ta metoda jest wywoływana. Wyobrażać sobie

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

który jest używany jak

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

Jeśli chcesz refaktoryzować, SomeMethod()aby zwrócić IEnumerable<MySecondClass>, musisz zmienić deklarację zmiennej (również wewnątrzforeach ) w każdym miejscu, w którym użyłeś metody.

Jeśli napiszesz

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

zamiast tego nie musisz tego zmieniać.

@aku: Jednym z przykładów są recenzje kodu. Innym przykładem są scenariusze refaktoryzacji.

Zasadniczo nie chcę iść na pisanie na klawiaturze za pomocą myszy. Może nie być dostępny.

To kwestia gustu. Całe to zamieszanie związane z typem zmiennej znika, gdy przyzwyczajasz się do dynamicznie wpisywanych języków. To znaczy, jeśli kiedykolwiek zaczniesz je lubić (nie jestem pewien, czy wszyscy mogą, ale tak).

C # varjest całkiem fajny, ponieważ wygląda jak pisanie dynamiczne, ale w rzeczywistości jest pisanie statyczne - kompilator wymusza prawidłowe użycie.

Typ twojej zmiennej nie jest tak naprawdę ważny (zostało to powiedziane wcześniej). Powinno być względnie jasne z kontekstu (jego interakcji z innymi zmiennymi i metodami) i jego nazwy - nie oczekuj, że lista klientów zawiera int...

Nadal czekam, aby zobaczyć, co mój szef myśli o tej sprawie - mam koc „śmiało”, aby używać nowych konstrukcji w 3.5, ale co zrobimy z konserwacją?

W porównaniu pomiędzy IEnumerable<int>i IEnumerable<double>nie musisz się martwić - jeśli podasz niewłaściwy typ, kod i tak się nie skompiluje.

Nie ma obaw o bezpieczeństwo typu, ponieważ nievar jest dynamiczne. To tylko magia kompilatora i wszelkie niebezpieczne połączenia, które wykonasz, zostaną złapane.

Var jest absolutnie potrzebny 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
    };

Spójrzmy teraz na anonEnumeration w intellisense, a pojawi się coś podobnegoIEnumerable<'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
}

Kompilator C # jest dość sprytny - typy anonów generowane osobno będą miały ten sam wygenerowany typ, jeśli ich właściwości będą pasować.

Poza tym, o ile masz inteligencję, sensowne jest używanie varwszędzie tam, gdzie kontekst jest jasny.

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

Myślę, że to zależy od twojej perspektywy. Osobiście nigdy nie miałem trudności ze zrozumieniem fragmentu kodu z powodu var„niewłaściwego użycia”, a moi współpracownicy i ja używam go dość często. (Zgadzam się, że Intellisense jest pod tym względem ogromną pomocą.) Z zadowoleniem przyjmuję to jako sposób na usunięcie powtarzającego się cruftu.

W końcu, jeśli stwierdzenia lubią

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

gdyby naprawdę nie można było sobie z tym poradzić, nikt nie używałby dynamicznie pisanych języków.

Używam var tylko wtedy, gdy jest jasne, aby zobaczyć, jaki typ jest używany.

Na przykład użyłbym var w tym przypadku, ponieważ od razu widać, że x będzie typu „MyClass”:

var x = new MyClass();

NIE używałbym var w takich przypadkach, ponieważ musisz przeciągnąć myszą nad kodem i spojrzeć na etykietkę, aby zobaczyć, jaki typ zwraca MyFunction:

var x = MyClass.MyFunction();

Szczególnie nigdy nie używam var w przypadkach, w których prawa strona nie jest nawet metodą, a jedynie wartością:

var x = 5;

(ponieważ kompilator nie może wiedzieć, czy chcę bajt, skrót, int lub cokolwiek)

Dla mnie antypatia do varilustruje, dlaczego dwujęzyczność w .NET jest ważna. Dla programistów C #, którzy również zrobili VB .NET, zalety varsą intuicyjnie oczywiste. Standardowa deklaracja C #:

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

odpowiada w VB .NET wpisaniu tego:

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

Jednak nikt nie robi tego w VB .NET. Byłoby głupio, ponieważ od czasu pierwszej wersji .NET mogłeś to zrobić ...

Dim whatever As New List(Of String)

... który tworzy zmienną i inicjuje wszystko w jednym stosunkowo kompaktowym wierszu. Ach, ale co jeśli chcesz IList<string>, nie List<string>? Cóż, w VB .NET oznacza to, że musisz to zrobić:

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

Tak jak trzeba to zrobić w języku C # i oczywiście nie można użyć vardo:

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

Jeśli potrzebujesz, aby ten typ był czymś innym, może być. Ale jedną z podstawowych zasad dobrego programowania jest ograniczenie redundancji i właśnie to robi var.

Używaj go do anonimowych typów - po to jest. Cokolwiek innego jest zbyt daleko posunięte. Jak wiele osób, które dorastały na C, jestem przyzwyczajony do patrzenia na lewą stronę deklaracji dla tego typu. Nie patrzę na prawą stronę, chyba że muszę. Używanie varjakiejkolwiek starej deklaracji sprawia, że ​​robię to cały czas, co osobiście uważam za niewygodne.

Ci, którzy mówią „to nie ma znaczenia, użyj tego, z czego jesteś zadowolony”, nie widzą całego obrazu. Każdy w pewnym momencie odbierze kod innej osoby i będzie musiał poradzić sobie z wszelkimi decyzjami podjętymi w momencie jej pisania. Wystarczająco źle jest mieć do czynienia z radykalnie odmiennymi konwencjami nazewnictwa lub - klasycznym mankamentem - wzmacniającymi stylami, bez dodawania całej varmieszanki „ albo nie”. Najgorszym przypadkiem będzie sytuacja, w której jeden programista nie używał, vara następnie pojawił się opiekun, który go uwielbia i rozszerza kod przy użyciu. Więc teraz masz bezbożny bałagan.

Standardy są dobrą rzeczą, ponieważ oznaczają, że istnieje większe prawdopodobieństwo, że będziesz w stanie pobrać losowy kod i szybko go odczytać. Im więcej rzeczy się różni, tym trudniej jest. A przejście do stylu „var wszędzie” jest duże różnicę.

Nie mam nic przeciwko pisaniu dynamicznemu i nie mam nic przeciwko wpisywaniu w sposób domyślny - w zaprojektowanych dla nich językach. Bardzo lubię Python. Ale język C # został zaprojektowany jako język o statycznym pisaniu i tak powinien pozostać. Łamanie reguł dla typów anonimowych było wystarczająco złe; pozwalanie ludziom pójść o krok dalej i przełamać idiomy języka jeszcze bardziej, jest czymś, z czego nie jestem zadowolony. Teraz, gdy dżin wyszedł z butelki, nigdy nie wróci. C # zostanie przeniesiony do obozów. Niedobrze.

Wiele razy podczas testowania mam taki kod:

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

Teraz czasami chcę zobaczyć, co zawiera SomeOtherThing, SomeOtherThing nie jest tego samego typu, co zwraca CallMethod (). Ponieważ używam var, po prostu zmieniam to:

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

do tego:

var something = myObject.SomeProperty.SomeOtherThing;

Bez var musiałbym ciągle zmieniać zadeklarowany typ po lewej stronie. Wiem, że to niewielkie, ale bardzo wygodne.

Dla entuzjastów, którzy myślą varoszczędzają czas, potrzeba mniejszej liczby naciśnięć klawiszy:

StringBuilder sb = new StringBuilder();

niż

var sb = new StringBuilder();

Policz je, jeśli mi nie wierzysz ...

19 kontra 21

Wyjaśnię, jeśli będę musiał, ale po prostu spróbuj ... (w zależności od aktualnego stanu twojej inteligencji może być konieczne wpisanie kilku kolejnych dla każdego)

Dotyczy to każdego rodzaju, o jakim możesz pomyśleć !!

Moim osobistym odczuciem jest to, że var nie powinien być nigdy używany, chyba że typ nie jest znany, ponieważ zmniejsza on czytelność rozpoznawania w kodzie. Rozpoznanie typu zajmuje więcej czasu niż mózgowi pełnej linii. Dawni timery, którzy rozumieją kod maszynowy i bity, dokładnie wiedzą o czym mówię. Mózg przetwarza równolegle, a kiedy używasz var, zmuszasz go do szeregowania danych wejściowych. Dlaczego ktokolwiek miałby chcieć, aby ich mózg pracował ciężej? Po to są komputery.

Dzielę var na wszystkie miejsca, jedyne wątpliwe miejsca dla mnie to wewnętrzne typy krótkie, np. Wolę int i = 3;więcejvar i = 3;

Z pewnością może to uprościć, z kodu, który napisałem wczoraj:

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

Bez tego byłby to bardzo gadatliwy var.

Dodatek: Trochę czasu spędzonego na języku z wnioskowaniem typu rzeczywistego (np. F #) pokaże, jak dobre są kompilatory w poprawnym typowaniu wyrażeń. Z pewnością oznaczało to, że zwykle używam vartyle, ile mogę, a użycie jawnego typu wskazuje teraz, że zmienna nie jest typu wyrażenia inicjującego.

Brak, z tym wyjątkiem, że nie musisz dwa razy wpisywać nazwy typu. http://msdn.microsoft.com/en-us/library/bb383973.aspx