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.
źródło
var i = 0;
== niepowodzenie!var c = new CrazyFrigginLongClassName();
== wygraj!var readabilityBeDamned = true;
Odpowiedzi:
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: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:
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>
doIList<Order>
) to muszę również zmienić tę deklarację - coś, czego nie musiałbym zrobić, gdybym użył var w pierwszym miejsce.źródło
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.
var
idzie 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
var
zadeklarowanej zmiennej i mylę się, po co jest zmienna, w moim kodzie jest coś zasadniczo nie tak.var
nie jest przyczyną, powoduje jedynie, że objawy są widoczne. Nie obwiniaj posłańca.Teraz zespół C # wydał wytyczne dotyczące kodowania, które
var
powinny być używane tylko do przechwytywania wyniku instrukcji LINQ, która tworzy typ anonimowy (ponieważ tutaj nie mamy prawdziwej alternatywyvar
). 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ć,
var
ale nadal uważam, że są w dużej mierze błędne. Weźmy przykład „wyszukiwalności”: autor twierdzi, żevar
utrudnia to wyszukiwanie miejsc, w którychMyType
jest 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).źródło
var
przyczynia się do zamieszania. Z pewnością mogą zdarzyć się przypadki, w których ważne jest podkreślenie rodzaju / wielkości zmiennej (np. Operacje bitowe niskiego poziomu). W porządku: nikt nigdy nie twierdził, żevar
należy go używać wyłącznie. Zasada jest prosta: jeśli naprawdę powoduje zamieszanie, nie używaj jej.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 zwraca
List<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.źródło
Żadne z nich nie jest absolutnie prawdziwe;
var
może mieć zarówno pozytywny, jak i negatywny wpływ na czytelność. Moim zdaniemvar
powinien być stosowany, gdy spełniony jest jeden z poniższych warunków:var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating()
)var
nie 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.źródło
typedef
wtedy, gdy nie jest.var
gdy typ jest oczywisty? Może, ale prawdziwy zysk ma miejsce, gdy typ nie ma znaczenia. Jeśli robisz takie rzeczyvar customers = whatever; var query = from c in customers select stuff
, nie ma znaczenia, jaki dokładnie jest rodzaj „klientów”. To oczywiste, jak możesz z niego korzystać i to wystarczy. A jeśli rzeczywisty typ jest uciążliwy, warto go stłumić.using ShortType = LongGenericType<A,B,C>
dyrektywę na górze pliku, ponieważ daje to taką samą czytelność, nie wymaga ponownego tworzenia konstruktorów i nie eliminuje klas potomnych z kandydatów.Eric Lippert, starszy inżynier oprogramowania w zespole C #:
Dlaczego
var
wprowadzono słowo kluczowe?Podkreśl moje. Cały artykuł, C # 3.0 jest wciąż statycznie wpisany, szczerze! , a kolejne serie są całkiem dobre.
Po to
var
jest. 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:var
jest wymagana , aby niektóre inne funkcje działały w .NET.źródło
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:
Gdyby było mniej więcej tak:
... 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:
... ale to ma sens:
Chyba każdy na swój. Przekonałem się, że robię to, co jest po prostu szalone:
Potrzebuję 12-etapowego programu var. Nazywam się Matt i ja (ab) używam var.
źródło
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,
jest zabronione przez nasze standardy kodowania, ale nasz zespół zachęca do następujących działań, ponieważ zwiększa to czytelność:
źródło
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
: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:EDYCJA : Zaktualizowałem ostatnią próbkę kodu na podstawie danych wejściowych Juliana
źródło
variable
tworzona jest zmienna lokalna o nazwie ? O ile nie poszerzysz swojego przykładu, nie jest to zbyt solidna skarga, IMO.variable
,CallMe
) stanowią złe przykłady. Gdyby jednakCallMe()
była funkcja w jakiejś „aplikacji telefonicznej”,var call = CallMe(); .... call.HangUp();
miałaby znacznie większy sens.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.
źródło
var
która nie ma z tym nic wspólnegoVariant
.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:
(proszę nie edytować hscroll powyżej - to trochę potwierdza sens !!!)
vs:
Są jednak sytuacje, w których jest to mylące i może potencjalnie powodować błędy. Zachowaj ostrożność,
var
jeśli oryginalna zmienna i typ inicjowany nie były identyczne. Na przykład:źródło
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ą.
źródło
Nie rozumiem o co chodzi ...
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:
i redukując ten totalny bałagan do:
Fajnie, nie tak ładnie jak:
Ale do tego właśnie służy Boo .
źródło
v = List<somethinglongtypename>();
nie jest nawet milszy. Ważne jest rozróżnienie między wprowadzaniem nowej zmiennej a przypisywaniem do istniejącej zmiennej.Jeśli ktoś używa
var
słowa kluczowego, ponieważ nie chce „ustalić typu”, jest to zdecydowanie zły powód. Słowovar
kluczowe 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
var
słowa kluczowego są na przykład: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.
źródło
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
Jest o wiele łatwiejszy lub trudniejszy do odczytania niż:
źródło
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
źródło
Jasne,
int
jest łatwe, ale gdy typem zmiennej jestIEnumerable<MyStupidLongNamedGenericClass<int, string>>
, var znacznie ułatwia.źródło
int
versusvar
jest czymś, o co można się sprzeczać, ale wiele zagnieżdżonych rodzajów ogólnychvar
stanowi dar niebios. W tym miejscu wielokrotne używanie nazwy typu niszczy czytelność kodu.class IntStringEnumerator : IEnumerable<MyStupidLongNamedGenericClass<int, string>>
a następnie użyj nowej nazwy. To czyści kod i lepiej opisuje typ.IntStringEnumerator i = new IntStringEnumerator()
wciąż jest za dużo pisania.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:
MyObject m = new ();
Lub jeśli przekazujesz parametry:
Osoba p = nowa („FirstName”, „LastName);
Gdzie podczas tworzenia nowego obiektu kompilator określa typ z lewej strony, a nie z prawej. Ma to inne zalety w porównaniu z „var”, ponieważ może być również użyte w deklaracjach polowych (istnieją również inne obszary, które mogą być przydatne, ale nie będę się tutaj zajmował).
Ostatecznie nie miało to na celu zmniejszenia nadmiarowości. Nie zrozum mnie źle, „var” jest BARDZO ważne w C # dla anonimowych typów / projekcji, ale użycie tutaj jest po prostu DALEKIE (i mówiłem to od dłuższego czasu), ponieważ zaciemniasz typ, który jest używany. Konieczność dwukrotnego wpisania jest zbyt często, ale deklarowanie go zero razy to za mało.
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:
jest w porządku, ale w takim przypadku:
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.
źródło
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
który jest używany jak
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
zamiast tego nie musisz tego zmieniać.
źródło
@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.
źródło
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 #
var
jest 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ą?
źródło
W porównaniu pomiędzy
IEnumerable<int>
iIEnumerable<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ż nie
var
jest dynamiczne. To tylko magia kompilatora i wszelkie niebezpieczne połączenia, które wykonasz, zostaną złapane.Var
jest absolutnie potrzebny Linq:Spójrzmy teraz na anonEnumeration w intellisense, a pojawi się coś podobnego
IEnumerable<'a>
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
var
wszędzie tam, gdzie kontekst jest jasny.źródło
IQueriable<T>
przed iteracją:anonEnumeration.ToList();
IQueryable
ani.ToList()
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 };
nie zwracaIQueriable<T>
?AllPosts()
zwraca - pytający odnosi się,List<T>
więc założyłem, że. W takim przypadku wynikiemanonEnumeration
będzie typIEnumerable<'a>
. Teraz, jeśli zamiast tego nastąpiAllPosts()
zwrot,IQueryable<T>
toanonEnumeration
stanie sięIQueryable<'a>
(uwaga niei
w Queryable) - jednak w takim przypadku mój kod nadal działa, ponieważIQueryable<T>
implementujeIEnumerable<T>
. Jest mnóstwo lepszych pytań i odpowiedzi na temat różnic między nimi - tutaj mój przypadek'a
jest anonimowy ivar
pozwala przypisać go do zmiennej o typie statycznym.IQueryable<T>
nie jest dobrą praktyką, ponieważ w każdej iteracji robisz instrukcję read w DB. Pamiętaj, aby to zrobić*.ToList()
IQueryable<T>
przed iteracją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ą
gdyby naprawdę nie można było sobie z tym poradzić, nikt nie używałby dynamicznie pisanych języków.
źródło
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”:
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:
Szczególnie nigdy nie używam var w przypadkach, w których prawa strona nie jest nawet metodą, a jedynie wartością:
(ponieważ kompilator nie może wiedzieć, czy chcę bajt, skrót, int lub cokolwiek)
źródło
var
,var
oznacza to, że nie ma problemu: problemem jest prawa strona. Nie jest wystarczająco opisowy .Customer c = GetContext()
jest nadal niejasne i nie lepsze niż używanievar
.Dla mnie antypatia do
var
ilustruje, dlaczego dwujęzyczność w .NET jest ważna. Dla programistów C #, którzy również zrobili VB .NET, zaletyvar
są intuicyjnie oczywiste. Standardowa deklaracja C #:odpowiada w VB .NET wpisaniu tego:
Jednak nikt nie robi tego w VB .NET. Byłoby głupio, ponieważ od czasu pierwszej wersji .NET mogłeś to zrobić ...
... który tworzy zmienną i inicjuje wszystko w jednym stosunkowo kompaktowym wierszu. Ach, ale co jeśli chcesz
IList<string>
, nieList<string>
? Cóż, w VB .NET oznacza to, że musisz to zrobić:Tak jak trzeba to zrobić w języku C # i oczywiście nie można użyć
var
do: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.
źródło
var
w C # nie ma żadnego połączenia zvar
JavaScript.var
-Declared zmienna w C # jest silnie wpisany.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
var
jakiejkolwiek 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
var
mieszanki „ albo nie”. Najgorszym przypadkiem będzie sytuacja, w której jeden programista nie używał,var
a 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.
źródło
Wiele razy podczas testowania mam taki kod:
Teraz czasami chcę zobaczyć, co zawiera SomeOtherThing, SomeOtherThing nie jest tego samego typu, co zwraca CallMethod (). Ponieważ używam var, po prostu zmieniam to:
do tego:
Bez var musiałbym ciągle zmieniać zadeklarowany typ po lewej stronie. Wiem, że to niewielkie, ale bardzo wygodne.
źródło
Dla entuzjastów, którzy myślą
var
oszczędzają czas, potrzeba mniejszej liczby naciśnięć klawiszy:niż
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.
źródło
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;
źródło
Z pewnością może to uprościć, z kodu, który napisałem wczoraj:
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
var
tyle, ile mogę, a użycie jawnego typu wskazuje teraz, że zmienna nie jest typu wyrażenia inicjującego.źródło
Brak, z tym wyjątkiem, że nie musisz dwa razy wpisywać nazwy typu. http://msdn.microsoft.com/en-us/library/bb383973.aspx
źródło