Użycie słowa kluczowego var w C#

Używam var intensywnie. Krytykowano, że zmniejsza to czytelność Kodeksu, ale nie ma żadnego argumentu na poparcie tego twierdzenia.

Może to oznaczać, że nie jest jasne, z jakim typem mamy do czynienia. I co z tego? To jest właśnie cel oddzielonej konstrukcji. Kiedy mamy do czynienia z interfejsami, dobitnie nie interesuje Cię typ zmiennej. var idzie o wiele dalej, prawda, ale myślę, że argument pozostaje ten sam z punkt widzenia czytelności: programista nie powinien być zainteresowany typem zmiennej, ale raczej tym, co robi zmienna . Dlatego też Microsoft nazywa Typ inference " pisaniem kaczki."

Więc, co robi zmienna, gdy deklaruję ją za pomocą var? Spokojnie, robi to, co mówi IntelliSense. Wszelkie rozumowania dotyczące C#, które ignorują IDE, nie są zgodne z rzeczywistością. W praktyce każdy kod C# jest zaprogramowany w IDE, które obsługuje IntelliSense.

Jeśli używam var zadeklarowanej zmiennej i się mylić, co zmienna jest tam, jest coś zasadniczo nie tak z moim kodem. var nie jest przyczyną, tylko sprawia, że objawy są widoczne. Nie wiń Posłańca.

Teraz, zespół C# opublikował wytyczne kodowania stwierdzające, że var powinno tylko być używane do przechwytywania wyniku instrukcji LINQ, która tworzy anonimowy Typ (ponieważ tutaj nie mamy prawdziwej alternatywy dla var). Pieprzyć to. Tak długo, jak zespół C# nie da mi solidnego argumentu za tą wytyczną, będę ją ignorował, ponieważ w mojej profesjonalnej i osobistej opinii, to czysta bzdura. (Sorry; nie mam linku do omawianych wytycznych.)

Właściwie, są pewne (powierzchownie) dobre wyjaśnienia na temat tego, dlaczego nie powinieneś używać var, ale nadal uważam, że są one w dużej mierze błędne. Weźmy przykład "searchabilty": Autor twierdzi, że var utrudnia wyszukiwanie miejsca, w których używane jest MyType. Racja. Interfejsy też. Właściwie, dlaczego miałbym chcieć wiedzieć, gdzie jest używana Klasa? Mogę być bardziej zainteresowany tym, gdzie jest instancjowany i nadal będzie to możliwe do przeszukiwania, ponieważ gdzieś musi być wywołany jego konstruktor(nawet jeśli odbywa się to pośrednio, nazwa typu musi być gdzieś wymieniona).

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

Z mojej perspektywy, za pomocą dobrych konwencje nazewnictwa zmiennych i metod są ważniejsze z punktu widzenia czytelności niż jawne informacje typu. Jeśli potrzebuję informacji o typie, zawsze mogę najechać kursorem na zmienną (w VS) i ją pobrać. Ogólnie rzecz biorąc, wyraźne informacje o typie nie powinny być konieczne dla czytelnika. Dla programisty, w VS nadal otrzymujesz Intellisense, niezależnie od tego, jak zmienna jest zadeklarowana. Mimo wszystko, nadal mogą być przypadki, w których ma sens wyraźne deklarowanie Typ -- być może masz metodę, która zwraca List<T>, ale chcesz traktować ją jako IEnumerable<T> w swojej metodzie. Aby upewnić się, że używasz interfejsu, zadeklarowanie zmiennej typu interface może uczynić to jawnym. Albo, być może, chcesz zadeklarować zmienną bez wartości początkowej - ponieważ natychmiast otrzymuje wartość na podstawie jakiegoś warunku. W takim razie potrzebujesz tego typu. Jeśli informacje o typie są użyteczne lub konieczne, użyj ich. Mam jednak wrażenie, że typowo 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; var może mieć zarówno pozytywny, jak i negatywny wpływ na czytelność. Moim zdaniem, var powinno być używane, gdy jedno z poniższych jest prawdziwe:

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

var nie ma wpływu na wydajność, ponieważ jest cukrem składniowym; kompilator wywiera typ i definiuje go po skompilowaniu do IL; nie ma w nim nic w rzeczywistości dynamicznego.

W 2004 roku, w ramach projektu C#, został członkiem C # team, a w 2006 roku został członkiem C # team.]}

Dlaczego wprowadzono słowo kluczowe var?

Istnieją dwa powody, jeden, który istnieje dzisiaj, taki, który pojawi się w 3.0.

Pierwszy powód jest taki, że ten kod jest niesamowicie brzydki ze względu na wszystkie redundancja:

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

I to jest prosty przykład – mam napisane gorzej. / Align = "left" / aby wpisać dokładnie to samo dwa razy, to jest redundancja, którą możemy usunąć Dużo ładniej pisać

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

I niech kompilator wykona co typ jest oparty na przypisaniu.

Po Drugie, C # 3.0 wprowadza anonymous typy. Od anonimowych typów przez definicja nie ma nazw, trzeba aby być w stanie wywnioskować rodzaj zmienna z inicjalizacji wyrażenie, Jeśli jego typ jest anonimowy.

Po to jest var. Inne zastosowania prawdopodobnie nie będą działać tak dobrze. Każde porównanie do JScript, VBScript lub dynamic typing jest totalne. Uwaga ponownie, var jest wymagane , 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 bardziej tak:

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

... wtedy ktoś czytający kod byłby znacznie bardziej skłonny zrozumieć, czym jest" lista". Jeśli masz kontrolę nad samą nazwą zmiennej list, to jeszcze lepiej.

var x = SaveFoo(foo);

... ale to ma sens:

var saveSucceeded = SaveFoo(foo);

var f = (float)3;

Przyjęliśmy etos "kod dla ludzi, a nie maszyn", opierając się na założeniu, że spędzasz wiele razy dłużej w trybie konserwacji niż na nowych pracach.

Dla mnie, to wyklucza argument, że kompilator "wie", jakiego typu jest zmienna-jasne, nie możesz napisać nieprawidłowego kodu za pierwszym razem, ponieważ kompilator zatrzymuje kod przed kompilacją, ale gdy następny programista czyta kod w ciągu 6 miesięcy, muszą być w stanie wydedukować, co robi zmienna prawidłowo lub nieprawidłowo i szybko zidentyfikować przyczynę problemów.

Tak więc,

var something = SomeMethod();

Jest zakazane przez nasze standardy kodowania, ale w naszym zespole zachęcamy 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 rzecz stylistyczna, która wydaje się być subiektywna. Może dodawać niespójności, kiedy używasz var, a kiedy nie.

Kolejny przypadek niepokojący, w poniższym wywołaniu nie można stwierdzić po prostu patrząc na kod typu zwracanego przez CallMe:

var variable = CallMe();

Używam var kiedy deklaruję anonimowe delegaty w metodach, var wygląda w jakiś sposób czystszy niż gdybym używał Func. Rozważ to kod:

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

EDIT : Zaktualizowano ostatnią próbkę kodu na podstawie danych wejściowych Juliana

Var nie jest jak variant w ogóle. Zmienna jest nadal mocno wpisana, po prostu nie naciska się klawiszy, aby ją w ten sposób uzyskać. Możesz najechać na niego kursorem w Visual Studio, aby zobaczyć Typ. Jeśli czytasz drukowany kod, możliwe, że będziesz musiał trochę 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 rzeczy przyzwoitym nazwom jest nadal najlepszym sposobem, aby Twój kod był łatwiejszy do naśladowania.

Czy używanie Intellisense jest leniwe? Mniej pisze niż całe nazwisko. A może 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 będzie potrzebny dla anonimowych typów (gdzie jest to wymagane w 100%); ale również unika powtarzania w błahych przypadkach, i IMO sprawia, że linia jaśniejsza. Nie muszę widzieć tego typu dwa razy dla prostej inicjalizacji.

Na przykład:

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

(proszę nie edytować hscrolla w powyższym-to trochę dowodzi sensu!!!)

Vs:

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

Są jednak sytuacje, kiedy jest to mylące i może potencjalnie powodować błędy. Ostrożnie. używając var, jeśli zmienna oryginalna i typ inicjalizacji 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ądanie kodu offline, szczególnie tych wykonanych na papierze.

Nie możesz polegać na myszach.

Nie wiem, w czym problem..

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

Nadal masz pełną inteligencję na temat 'czegoś', a dla każdego dwuznacznego przypadku masz swoje testy jednostkowe, prawda? a Ty? )

To nie jest varchar, to nie jest słabe, a na pewno nie jest dynamiczne lub słabe pisanie. Zatrzymuje maddnes Tak:

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

I redukując ten całkowity mindclutter do:

var v = new List<somethinglongtypename>();

v = List<somethinglongtypename>();

Ale po to jest Boo .

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

Dobre powody, aby używać słowa kluczowego var są na przykład:

• tam, gdzie jest to potrzebne, tzn. aby zadeklarować odniesienie do anonimowego Typ.
• gdzie czyni kod bardziej czytelnym, tzn. usuwa deklaracje powtarzające się.

Wypisanie typu danych często ułatwia śledzenie kodu. Pokazuje, jakich typów danych używasz, dzięki czemu nie musisz ustalać typu danych, najpierw zastanawiając się, co robi kod.

Biorąc pod uwagę, jak potężny Intellisense jest teraz, nie jestem pewien, czy Var jest trudniejszy do odczytania niż posiadanie zmiennych członkowskich w klasie lub zmiennych lokalnych w metodzie, które są zdefiniowane poza widocznym obszarem ekranu.

Jeśli masz linię kodu taką jak

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

Jest o wiele łatwiejsze lub trudniejsze 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, tzn. podczas robienia rzeczy w Linq, które ułatwia (i prawdopodobnie w innych przypadkach).

Jeśli masz typ na coś w then, powinieneś go użyć - nie jest to zwykłe lenistwo (w przeciwieństwie do lenistwa twórczego, które ogólnie należy zachęcać - dobrzy programiści często ciężko pracują, aby być leniwym i można je uznać za źródło rzeczy w pierwszej kolejności).

Koc zakaz jest tak zły jako nadużycie konstrukcji w pierwszej kolejności, ale nie musi być sensowny standard kodowania.

Inną rzeczą do zapamiętania jest to, że nie jest to var typu VB, ponieważ nie może zmieniać typów-to jest zmienna silnie wpisana jej tylko to, że typ jest wywnioskowany (dlatego są ludzie, którzy będą twierdzić, że nie jest nieuzasadnione użycie go w, powiedzmy, foreach, ale nie zgadzam się ze względu zarówno na czytelność, jak i konserwowalność).

Podejrzewam, że ten ucieknie I run ( - :

Murph

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

Skradziony z post w tej sprawie w CodingHorror :

niestety, ty i wszyscy inni się pomyliliście. Chociaż zgadzam się z Tobą, że redundancja nie jest dobrą rzeczą, lepszym sposobem rozwiązania tego problemu byłoby zrobienie czegoś takiego jak:

MyObject m = new ();

Lub jeśli przekazujesz parametry:

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

Gdzie przy tworzeniu nowego obiektu kompilator wywiera typ Z Lewej strony, a nie z prawej. Ma to inne zalety niż "var", ponieważ może być również używany w deklaracjach pól (są też inne obszary, w których może być również przydatny, ale nie będę się tutaj wtrącał).

Nicholas Paldino. Net / C # MVP on June 20, 2008 08:00 am

Myślę, że jeśli twoim głównym zmartwieniem jest to, że musisz pisać mniej -- to nie ma żadnego argumentu, który powstrzyma cię od korzystania z niego.

var people = Managers.People

var fc = Factory.Run();

W przeciwnym razie po prostu wykorzystaj swój najlepszy osąd i programową "uprzejmość" wobec innych, którzy będą musieli pracować nad Twoim projektem.

Użycie var zamiast jawnego typu znacznie ułatwia refaktoryzację (dlatego muszę zaprzeczyć poprzednim plakatom, które miały na myśli, że nie robi różnicy lub był to czysto "cukier składniowy").

Możesz zmienić typ zwracanych metod bez zmiany KAŻDEGO pliku, w którym ta metoda jest wywoływana. Imagine

...
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 refaktor SomeMethod() aby zwrócić IEnumerable<MySecondClass>, musisz zmienić deklarację zmiennej (również wewnątrz foreach) w każdym miejscu używał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.

W zasadzie nie chcę polować na typ z moją myszką. Może nie być dostępna.

To kwestia gustu. Wszystkie te problemy dotyczące typu zmiennej znikają, gdy przyzwyczaisz się do dynamicznie wpisywanych języków. To znaczy, Jeśli kiedykolwiek zaczniesz je lubić(nie jestem pewien, czy każdy może, ale ja tak).

C#'S var jest całkiem fajne, ponieważ wygląda jak dynamiczne pisanie, ale w rzeczywistości jest to statyczne pisanie - kompilator wymusza poprawne użycie.

Typ zmiennej nie jest tak naprawdę tak ważny (zostało to powiedziane przed). Powinien być stosunkowo jasny z kontekstu (jego interakcji z innymi zmiennymi i metodami) i jego nazwy - nie oczekuj, że customerList będzie zawierać int...

Nadal czekam na to, co mój szef myśli o tej sprawie - mam koc "śmiało", aby użyć 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, Twój kod i tak się nie skompiluje.

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

Var jest absolutnie potrzebne dla 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ójrz teraz na anonEnumeration w intellisense i pojawi się coś w stylu 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
}

Kompilator C# jest całkiem sprytne - typy anon generowane oddzielnie będą miały ten sam wygenerowany Typ, jeśli ich właściwości pasują.

Poza tym, tak długo, jak masz intellisense, ma sens używać var wszę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;

To chyba 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żywamy go dość często. (Zgadzam się, że Intellisense jest ogromną pomocą w tym zakresie.) Z zadowoleniem przyjmuję to jako sposób na usunięcie powtarzalnego cruft.

W końcu, jeśli wypowiedzi takie jak

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 było to niemożliwe, nikt nie używałby dynamicznie pisanych języków.

Używam var tylko wtedy, gdy jest jasne, 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ąć kursor myszy na kod i spojrzeć na tooltip, aby zobaczyć, jaki typ zwraca Mojafunction:

var x = MyClass.MyFunction();

Szczególnie, ja Nigdy nie używam var w przypadkach, gdy prawa strona nie jest nawet metodą, a tylko wartość:

var x = 5;

(ponieważ kompilator nie może wiedzieć, czy chcę bajt, krótki, int czy cokolwiek)

Dla mnie antypatia wobec var ilustruje, dlaczego dwujęzyczność w. NET jest ważna. Dla programistów C#, którzy również stworzyli VB. NET, zalety var są intuicyjnie oczywiste. Standardowa deklaracja C#:

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

Jest odpowiednikiem, w VB. NET, wpisując to:

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

Nikt tego nie robi w VB. NET. To byłoby głupie, ponieważ od pierwszej wersji. NET jesteś w stanie to zrobić...

Dim whatever As New List(Of String)

...który tworzy zmienną i inicjalizuje to wszystko w jednej dość zwartej linii. Ah, ale co jeśli chcesz IList<string>, a 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 w C#, i oczywiście nie można użyć var dla:

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

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

Użyj go dla anonimowych typów - po to jest. Wszystko inne jest za daleko. Podobnie jak wielu ludzi, którzy dorastali na C, jestem przyzwyczajony do patrzenia na lewo od deklaracji dla typu. Nie patrzę na prawą stronę, chyba że muszę. Używanie var dla każdej starej deklaracji sprawia, że robię to cały czas, co osobiście uważam za niewygodne.

Standardy to dobra rzecz właśnie dlatego, że oznaczają, że jesteś o wiele bardziej prawdopodobne, aby być w stanie odebrać losowy kod i być w stanie grok go szybko. Im więcej rzeczy jest innych, tym trudniej. A przejście do stylu' var everywhere ' robi dużą różnicę.

Wiele razy podczas testowania, znajduję się mając taki kod:

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

Teraz, czasami, będę chciał zobaczyć, co zawiera SomeOtherThing, SomeOtherThing nie jest tym samym typem, który zwraca CallMethod (). Ponieważ jednak używam var, po prostu to zmieniam:

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

Do tego:

var something = myObject.SomeProperty.SomeOtherThing;

Bez var, musiałbym ciągle zmieniać deklarowany Typ po lewej stronie. Wiem, że to drobne, ale bardzo wygodne.

Dla miłośników, którzy myślą, że var oszczędza czas, potrzeba mniej naciśnięć klawiszy, aby wpisać:

StringBuilder sb = new StringBuilder();

Niż

var sb = new StringBuilder();

19 kontra 21

I to prawda dla każdego typu można myśleć!!

Moje osobiste odczucie jest takie, że var nigdy nie powinien być używany, chyba że typ jest nie jest znany, ponieważ zmniejsza rozpoznawalność odczytu w kodzie. Mózg rozpoznaje typ dłużej niż pełna linia. Starzy ludzie, którzy rozumieją kod maszynowy i bity, wiedzą dokładnie, o czym mówię. Mózg przetwarza się równolegle i kiedy używasz var, zmuszasz go do serializacji jego danych wejściowych. Dlaczego ktoś chciałby, aby ich mózg pracował ciężej? Po to są komputery.

Dzielę var na wszystkie miejsca, jedyne wątpliwe dla mnie miejsca to wewnętrzne krótkie typy, np. wolę int i = 3; nad var 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) { ... }

To byłoby bardzo gadatliwe bez var.

Dodatek: trochę czasu spędzonego z językiem z rzeczywistym wnioskowaniem typu (np. F#) pokaże, jak dobre są Kompilatory w poprawnym doborze typu wyrażeń. Z pewnością oznaczało to, że używam var jak najwięcej, a użycie jawnego typu wskazuje teraz, że zmienna nie jest typu inicjującego wyrażenia.

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