Czy Microsoft zniechęca do używania „var” w C #? (VS2017)

Patrzę na nadchodzące Visual Studio 2017 .

W sekcji zatytułowanej Zwiększona wydajność znajduje się obraz Visual Studio używany do zastąpienia wszystkich wystąpień var jawnym typem.

Kod najwyraźniej ma kilka problemów, które Visual Studio zidentyfikowało jako „wymaga naprawy”.

Chciałem dokładnie sprawdzić moje rozumienie użycia var w C #, więc przeczytałem artykuł z 2011 roku autorstwa Erica Lipperta zatytułowany Zastosowania i niewłaściwe użycie niejawnego pisania .

Eric mówi:

Użyj var, kiedy musisz; gdy używasz anonimowych typów.

Użyj var, gdy typ deklaracji jest oczywisty z inicjalizatora, szczególnie jeśli jest to tworzenie obiektu. To eliminuje redundancję.

Rozważ użycie var, jeśli kod podkreśla semantyczny „cel biznesowy” zmiennej i lekceważy „mechaniczne” szczegóły jej przechowywania.

Użyj jawnych typów, jeśli jest to konieczne do poprawnego zrozumienia i utrzymania kodu.

Używaj opisowych nazw zmiennych niezależnie od tego, czy używasz „var”. Nazwy zmiennych powinny reprezentować semantykę zmiennej, a nie szczegóły jej przechowywania; „DecimalRate” jest złe; „Odsetki” są dobre.

Myślę, że większość użycia var w kodzie jest prawdopodobnie w porządku. Myślę, że byłoby dobrze nie używać var dla bitu, który czyta ...

var tweetReady = workouts [ ... ]

... bo może nie jest w 100% natychmiastowy, jaki to typ, ale nawet wtedy dość szybko wiem, że to jest boolean.

Var Wykorzystanie tej części ...

var listOfTweets = new List<string>();

... wygląda mi dokładnie na dobre użycie var, ponieważ uważam, że jest zbyteczne wykonywanie następujących czynności:

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

Mimo że na podstawie tego, co mówi Eric, zmienna powinna być raczej tweetami niż listOfTweetami .

Jaki byłby powód zmiany całego varwykorzystania tutaj? Czy coś jest nie tak z tym kodem, którego mi brakuje?

language-design visual-studio

— Rowan Freeman
źródło

Kod na zrzucie ekranu jest dokładnie tym, co zgadzasz się nie używać var ... Wyjaśnienie?

— Telastyn

Myślę, że wszystkie zastosowania vartutaj są w porządku. Możesz ewentualnie zmienić jeden - ale nawet wtedy myślę, że nie jest to naprawdę konieczne. Po co zmieniać je wszystkie na wyraźne?

— Rowan Freeman

Pamiętaj, że to, co jest oczywiste dla ludzi, nie zawsze jest oczywiste dla studia wizualnego.

— candied_orange

Wszystko? Na zrzucie ekranu występuje jeden błąd, który jest wyraźnie związany z var.

— Telastyn

Cóż, to nie jest błąd jako taki, ale raczej ostrzeżenie w rodzaju, którego można oczekiwać od liniowca. Zgodnie z obrazem wszystkie varszostały oznaczone w ten sam sposób; z tym samym ostrzegawczym krzyżem obok nich i czerwonym podkreśleniem. Przypuszczalnie Visual Studio chce je wszystkie poprawić w ten sam sposób. Chyba że się mylę.

— Rowan Freeman

Odpowiedzi:

TL; DR: nie, Microsoft nie zniechęca do używania „var” w C #. Obrazowi brakuje kontekstu, aby wyjaśnić, dlaczego narzeka.

W przypadku zainstalowania VS2017 RC i otworzyć panel Opcje i przejdź do Text Editor -> C#zobaczysz nową sekcję: Code Style. Jest to podobne do tego, co oferował ReSharper od pewnego czasu: zestaw konfigurowalnych reguł stylów kodowania.

Zawiera trzy opcje dotyczące użycia var: dla typów wbudowanych, gdy typ zmiennej jest widoczny i „Gdzie indziej”. W każdym przypadku możesz określić „preferuj typ jawny” lub „preferuj var” i ustaw poziom powiadomień na „brak”, „sugestia”, „ostrzeżenie” lub „błąd”:

— David Arno
źródło

Jakie jest domyślne? Jeśli „ustawienie fabryczne” to „Preferuj typ jawny”, można argumentować, że MS zniechęca do korzystania z niego var.

— JacquesB

@JacquesB, wartości domyślne są takie, jak pokazano na zrzucie ekranu. Ponieważ wszystkie są ustawione na „Brak”, trudno jest ustalić, czy „Preferuj typ jawny” jest aktywnie ustawiony jako preferowany sposób MS, czy też jest to tylko „wartość zerowa”. Jeśli chodzi o mnie, najlepsi twórcy popierają var, więc nie obchodzi mnie, jakie są poglądy państw członkowskich w tej sprawie.

— David Arno,

Myślę, że za dużo w to czytasz. Tak więc istnieje funkcja, która pozwala zastąpić użycie pisania niejawnego wyraźnymi adnotacjami typu, z czego można wywnioskować, że nie zaleca się pisania niejawnego. Istnieje również funkcja kompilacji C♯ do kodu bajtowego CIL. Czy wyciągnąłbyś z tego wniosek, że C♯ jest odradzane i wszyscy powinniśmy zamiast tego napisać bajt CIL? Prawdopodobnie nie.

Microsoft po prostu pokazuje głębokie zrozumienie IDE twojego kodu. Może nawet napisać dla Ciebie typy bez konieczności ich przeliterowania. Otóż to.

To po prostu dobry przykład pokazania możliwości rozumienia kodu przez IDE. Jest mały i niezależny (w przeciwieństwie do większego refaktoryzacji), jest dostępny we wszystkich wersjach i dotyczy wszystkich programistów (w przeciwieństwie do niektórych z bardzo imponujących funkcji wizualizacji architektonicznej, które są dostępne tylko w Ultimate i nie mają zastosowania do znacznej części potencjalnych użytkowników VS, którzy nigdy nie będą mieli tak dużych projektów) i chociaż jest to bardzo proste (dosłownie robi dokładnie to samo, csc.execo robi od tego czasuvarzostał wprowadzony), z pewnością wygląda imponująco, szczególnie dla kogoś, kto tak naprawdę nie rozumie niejawnego pisania i wnioskowania o typie (lub który próbuje google „wnioskowania o typie” i zostaje przytłoczony takimi terminami jak Hindley-Milner, unifikacja, cofanie, gdy w rzeczywistości Wnioskowanie tylko lokalnie dla C♯ jest niezwykle proste i jednoznaczne).

Krótko mówiąc: to efektowny sposób pokazania funkcji IDE.

— Jörg W Mittag
źródło