Использование ключевого слова var в С#

После обсуждения с коллегами относительно использования ключевого слова 'var' в С# 3 я задавался вопросом, какие мнения людей были в соответствующих случаях использования вывода типа через var?

Например, я довольно лениво использовал var в сомнительных обстоятельствах, например: -

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 следующие: -

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

Интересно, что LINQ кажется немного серой областью, например: -

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

Понятно, какие результаты будут в том, что это будет тип, который реализует IEnumerable, однако это не совсем очевидно так же, как var, объявляющий новый объект.

Это еще хуже, когда речь идет о LINQ для объектов, например: -

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

Это не лучше, чем equivalent foreach (элемент var в someList) {//...} equivilent.

Здесь существует серьезная проблема безопасности типов - например, если бы мы поставили результаты этого запроса в перегруженный метод, который принял IEnumerable <int> и IEnumerable <double> вызывающий может непреднамеренно передать неправильный тип.

var действительно поддерживает сильную типизацию, но вопрос в том, действительно ли это опасно для типа, чтобы он не сразу проявлялся в определении, то, что увеличивается при перегрузках, означает, что ошибки компилятора могут не выдаваться, когда вы непреднамеренно передаете неправильный тип метод.

Ответ 1

Я все еще думаю, что var может сделать код более читаемым в некоторых случаях. Если у меня есть класс Customer с свойством Orders, и я хочу назначить его переменной, я просто сделаю следующее:

var orders = cust.Orders;

Мне все равно, если Customer.Orders IEnumerable<Order>, ObservableCollection<Order> или BindingList<Order> - все, что я хочу, это сохранить этот список в памяти, чтобы перебрать его или получить его счет или что-то позже.

Контрастируйте вышеуказанное объявление с помощью:

ObservableCollection<Order> orders = cust.Orders;

Для меня имя типа - это просто шум. И если я вернусь и решит изменить тип клиента. Оверки по треку (скажем от ObservableCollection<Order> до IList<Order>), то мне тоже нужно изменить это объявление - что-то, что мне не нужно было бы делать, d использовал var в первую очередь.

Ответ 2

Я использую var экстенсивно. Была критика, что это уменьшает читабельность кода, но не аргументирует это утверждение.

По общему признанию, это может означать, что не ясно, с каким типом мы имеем дело. И что? На самом деле это точка развязанного дизайна. При работе с интерфейсами вы категорически не заинтересованы в типе, который имеет переменная. var принимает это намного больше, правда, но я думаю, что аргумент остается неизменным с точки зрения удобочитаемости: программисту не нужно фактически интересоваться типом переменной, а скорее тем, что делает переменная. Вот почему Microsoft также вызывает вывод типа "утиная печать".

Итак, что делает переменная, когда я объявляю ее с помощью var? Легко, он делает то, что IntelliSense говорит мне об этом. Любые рассуждения о С#, которые игнорируют IDE, не соответствуют действительности. На практике каждый код С# программируется в среде IDE, которая поддерживает IntelliSense.

Если я использую объявленную переменную var и путаю, для чего нужна переменная, в коде есть что-то принципиально неправильное. var не является причиной, это только делает видимыми симптомы. Не обвиняйте посланника.

Теперь команда С# выпустила руководство по кодированию, в котором указано, что var следует использовать только для захвата результата оператора LINQ, который создает анонимный тип (потому что здесь у нас нет реальной альтернативы var). Ну, прикрутите это. Пока команда С# не дает мне обоснованного аргумента для этого руководства, я проигнорирую это, потому что, по моему профессиональному и личному мнению, это чистый балони. (Извините, у меня нет ссылки на соответствующий ориентир.)

Собственно, есть некоторые (поверхностно) хорошие объяснения о том, почему вы не должны использовать var, но я все же считаю, что они в основном неправильны, Возьмем пример "searchabililty": автор утверждает, что var затрудняет поиск мест, где используется MyType. Правильно. Так же и интерфейсы. На самом деле, почему я хочу знать, где используется класс? Я мог бы быть более заинтересован в том, где он создан, и это все равно будет доступно для поиска, потому что где-то его конструктор должен быть вызван (даже если это делается косвенно, имя типа должно упоминаться где-то).

Ответ 3

Var, на мой взгляд, на С# - хорошая вещь tm. Любая типизированная переменная все еще строго типизирована, но она получает свой тип из правой части задания, где она определена. Поскольку информация о типе доступна с правой стороны, в большинстве случаев излишняя и чрезмерно многословная также должна вводить ее с левой стороны. Я думаю, что это значительно повышает читаемость без снижения безопасности типов.

С моей точки зрения использование хороших соглашений об именах для переменных и методов более важно с точки зрения читаемости, чем информация о явном типе. Если мне нужна информация о типе, я всегда могу навести курсор на переменную (в VS) и получить ее. Однако, как правило, явная информация о типе не должна быть необходима читателю. Для разработчика в VS вы все равно получаете Intellisense, независимо от того, как объявлена ​​переменная. Сказав все это, все еще могут быть случаи, когда имеет смысл явно объявить тип - возможно, у вас есть метод, который возвращает List<T>, но вы хотите рассматривать его как IEnumerable<T> в своем методе. Чтобы убедиться, что вы используете интерфейс, объявление переменной типа интерфейса может сделать это явным. Или, возможно, вы хотите объявить переменную без начального значения, потому что она сразу получает значение, основанное на некотором условии. В этом случае вам нужен тип. Если информация типа является полезной или необходимой, используйте ее и используйте. Я чувствую, что, как правило, это не обязательно, и в большинстве случаев код легче читать без него.

Ответ 4

Ни одно из них не является абсолютно истинным; var может иметь как положительные, так и отрицательные эффекты на читаемость. По-моему, var следует использовать, когда выполняется одно из следующих условий:

  • Тип анонимный (ну, у вас здесь нет выбора, так как в этом случае он должен быть var)
  • Тип очевиден на основе назначенного выражения (т.е. var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var не влияет на производительность, поскольку это синтаксический сахар; компилятор вводит тип и определяет его, как только он скомпилирован в IL; в этом нет ничего динамичного.

Ответ 5

От Эрика Липперта, старшего инженера по разработке программного обеспечения в команде С#:

Почему было введено ключевое слово var?

Существует две причины: существует сегодня, тот, который появится в 3.0.

Первая причина заключается в том, что этот код невероятно уродливый из-за всех избыточность:

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

И это простой пример - я написано хуже. Каждый раз, когда вы вынуждены набирать одно и то же дважды, что избыточность, которую мы можем Удалить. Намного приятнее писать

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

и дать компилятору понять, что тип основан на назначении.

Во-вторых, С# 3.0 вводит анонимный типы. Поскольку анонимные типы определение не имеет имен, вам требуется, чтобы быть в состоянии вывести тип переменная от инициализации выражение, если его тип анонимен.

Акцент мой. Вся статья, С# 3.0 все еще статически типизирована, честная! и последующая серии довольно хороши.

Это для var. Другие виды использования, вероятно, не будут работать так хорошо. Любое сравнение с JScript, VBScript или динамической типизацией является полной койкой. Запомните еще раз, var требуется , чтобы некоторые .NET-функции работали в .NET.

Ответ 6

Я думаю, что использование var должно сочетаться с разумно выбранными именами переменных.

У меня нет проблем с использованием var в инструкции foreach, если это не так:

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

Если бы это было больше похоже:

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

... тогда кто-то, читающий код, будет гораздо более правдоподобным, чтобы понять, что такое "список". Если у вас есть контроль над именем самой переменной списка, это еще лучше.

То же самое можно применить и к другим ситуациям. Это довольно бесполезно:

var x = SaveFoo(foo);

... но это имеет смысл:

var saveSucceeded = SaveFoo(foo);
Кажется, он сам по себе. Я обнаружил, что делаю это, что просто безумие:
var f = (float)3;

Мне нужна какая-то 12-ступенчатая программа var. Меня зовут Мэтт, и я (ab) использую var.

Ответ 7

Мы приняли этот принцип "Кодекс для людей, а не машин", исходя из предположения, что вы тратите в несколько раз больше времени на обслуживание, чем на новую разработку.

Для меня это исключает аргумент о том, что компилятор "знает", какой тип является переменной. Конечно, вы не можете писать неверный код в первый раз, потому что компилятор перестает компилировать ваш код, но когда следующий разработчик считывая код через 6 месяцев, они должны иметь возможность выводить то, что переменная делает правильно или неправильно, и быстро идентифицировать причину проблем.

Таким образом,

var something = SomeMethod();

объявляется вне закона нашими стандартами кодирования, но в нашей команде поощряется следующее, поскольку оно повышает удобочитаемость:

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

Ответ 8

Это не плохо, это больше стилистическая вещь, которая имеет тенденцию быть субъективной. Он может добавить несоответствия, когда вы используете var, а когда нет.

Еще один случай, вызывающий беспокойство, в следующем вызове вы не можете сказать, просто просмотрев код типа, возвращаемого CallMe:

var variable = CallMe();

Что моя главная жалоба на var.

Я использую var, когда объявляю анонимных делегатов в методах, поскольку var выглядит более чистым, чем если бы я использовал Func. Рассмотрим этот код:

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

EDIT: обновлен последний пример кода на основе ввода Джулиана

Ответ 9

Вар совсем не похож на вариант. Переменная все еще строго типизирована, просто вы не нажимаете клавиши, чтобы получить ее таким образом. Вы можете нависнуть над ним в Visual Studio, чтобы увидеть тип. Если вы читаете печатный код, возможно, вам, возможно, придется немного подумать над тем, что такое тип. Но есть только одна строка, которая заявляет об этом, и многие строки, которые ее используют, поэтому предоставление достойных имен по-прежнему является лучшим способом сделать ваш код более удобным.

Использует Intellisense ленивый? Это меньше печатает, чем все имя. Или есть вещи, которые меньше работают, но не заслуживают критики? Я думаю, что есть, и var является одним из них.

Ответ 10

Наиболее вероятное время, которое вам понадобится для анонимных типов (где требуется 100%); но он также избегает повторения для тривиальных случаев, а ИМО делает линию более четкой. Мне не нужно дважды видеть тип для простой инициализации.

Например:

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

(пожалуйста, не редактируйте hscroll в приведенном выше примере - это вроде бы доказывает точку!!!)

против

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

Однако есть случаи, когда это вводит в заблуждение и может вызвать ошибки. Будьте осторожны, используя var, если исходная переменная и инициализированный тип не были идентичны. Например:

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

Ответ 11

Один конкретный случай, когда var сложный: обзоры автономных кодов, особенно те, что сделаны на бумаге.

Вы не можете полагаться на мышь.

Ответ 12

Я не понимаю, в чем дело.

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

У вас все еще есть полное intellisense на "что-то", и для любого двусмысленного случая у вас есть свои модульные тесты, верно? (вы?)

Это не варчар, это не тускло, и это конечно не динамическая или слабая типизация. Это останавливает maddnes следующим образом:

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

и уменьшая этот общий уровень разума до:

var v = new List<somethinglongtypename>();

Приятно, не так приятно, как:

v = List<somethinglongtypename>();

Но тогда для Boo.

Ответ 13

Если кто-то использует ключевое слово var, потому что они не хотят "определять тип", это определенно неправильная причина. Ключевое слово var не создает переменную с динамическим типом, компилятор все еще должен знать тип. Поскольку переменная всегда имеет определенный тип, тип также должен быть очевидным в коде, если это возможно.

Хорошими причинами использования ключевого слова var являются, например:

  • Где это необходимо, т.е. объявить ссылку для анонимного типа.
  • Где он делает код более читаемым, т.е. удаляет повторяющиеся объявления.

Списание типа данных часто упрощает выполнение кода. Он показывает, какие типы данных вы используете, так что вам не нужно определять тип данных, сначала выясняя, что делает код.

Ответ 14

Учитывая, насколько мощным Intellisense является теперь, я не уверен, что var труднее читать, чем иметь переменные-члены в классе или локальные переменные в методе, который определен из видимой области экрана.

Если у вас есть строка кода, например

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

Чтение намного проще или труднее:

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

Ответ 15

Я думаю, что ключевая вещь с VAR заключается в том, чтобы использовать ее только там, где это необходимо, когда делаете что-то в Linq, что облегчает (и, возможно, в других случаях).

Если у вас есть тип чего-то в то, то вы должны его использовать - не делать это просто лень (в отличие от творческой лености, которую обычно поощряют), хорошие программисты очень трудны, чтобы быть ленивыми и можно считать источником вещи в первую очередь).

Запрет на одежде столь же плох, как и злоупотребление конструкцией в первую очередь, но там должен быть разумный стандарт кодирования.

Другая вещь, которую следует помнить, заключается в том, что ее не тип VB var в том, что он не может изменять типы - он - это строго типизированная переменная, только что тип выводится (вот почему это люди, которые будут утверждать, что его неразумно использовать его, скажем, в foreach, но я бы не согласился по соображениям удобочитаемости и ремонтопригодности).

Я подозреваю, что это будет запущено и запущено (-:

Мерф

Ответ 16

Конечно, int легко, но когда тип переменной IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var делает вещи намного проще.

Ответ 17

Украденное из сообщение об этой проблеме в CodingHorror:


К сожалению, вы и все остальные в значительной степени ошибались. Хотя я согласен с вами в том, что избыточность не очень хорошая, лучший способ решить эту проблему - сделать что-то вроде следующего:

MyObject m = new();

Или, если вы передаете параметры:

Лицо p = new ( "FirstName", "LastName" );

Где при создании нового объекта компилятор выводит тип с левой стороны, а не справа. Это имеет другие преимущества перед "var", поскольку оно также может использоваться в объявлениях полей (есть и некоторые другие области, которые могут быть полезны, но я не буду вдаваться в него здесь).

В конце концов, это просто не предназначалось для сокращения избыточности. Не поймите меня неправильно, "var" ОЧЕНЬ важно в С# для анонимных типов/прогнозов, но использование здесь просто отключено (и я говорил это долгое время), поскольку вы запутываете тип, который используется. Слишком часто вводить его дважды, но объявить его в нулевое время слишком мало.

Николай Палдино. NET/С# MVP 20 июня 2008 г. 08:00


Я думаю, если ваша главная проблема состоит в том, чтобы напечатать меньше - тогда нет никаких аргументов, которые могут повлиять на использование вами.

Если вы собираетесь только когда-либо быть человеком, который смотрит на ваш код, то кого это волнует? В противном случае, в таком случае:

var people = Managers.People

это нормально, но в таком случае:

var fc = Factory.Run();

он коротко замыкает любые немедленные выводы, которые мой мозг может начать формировать из "английского" кода.

В противном случае просто используйте свое лучшее суждение и "вежливость" программирования для других, которым, возможно, придется работать над вашим проектом.

Ответ 18

Использование var вместо явного типа делает рефакторинг намного проще (поэтому я должен противоречить предыдущим плакатам, которые означали, что это не имеет никакого значения, или это был чисто "синтаксический сахар" ).

Вы можете изменить возвращаемый тип своих методов, не изменяя каждый файл, где вызывается этот метод. Представьте себе,

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

который используется как

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

Если вы хотите реорганизовать SomeMethod() для возврата IEnumerable<MySecondClass>, вам нужно будет изменить объявление переменной (также внутри foreach) в каждом месте, где вы использовали метод.

Если вы пишете

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

вместо этого вам не нужно его менять.

Ответ 19

@aku: Один пример - обзоры кода. Другим примером являются сценарии рефакторинга.

В принципе, я не хочу идти на поиск с помощью мыши. Возможно, он недоступен.

Ответ 20

Это вопрос вкуса. Все это суетливость типа переменной исчезает, когда вы привыкаете к динамически типизированным языкам. То есть, если вы когда-нибудь начнете им нравиться (я не уверен, что все могут, но я знаю).

С# var довольно круто в том, что он похож на динамическую типизацию, но на самом деле это статический ввод - компилятор обеспечивает правильное использование.

Тип вашей переменной на самом деле не так важен (об этом говорилось ранее). Это должно быть относительно ясно из контекста (его взаимодействия с другими переменными и методами) и его именем - не ожидайте, что clientList будет содержать int...

Я все еще жду, чтобы понять, что мой босс думает об этом вопросе - я получил одеяло "вперед", чтобы использовать любые новые конструкции в 3.5, но что мы будем делать с обслуживанием?

Ответ 21

При сравнении между IEnumerable<int> и IEnumerable<double> вам не нужно беспокоиться - если вы передадите неправильный тип, ваш код не будет компилироваться в любом случае.

Не стоит беспокоиться о безопасности типов, поскольку var - не. Это просто магия компилятора и любые небезопасные вызовы, которые вы совершаете, будут пойманы.

var абсолютно необходимо для 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
    };

Теперь посмотрим на anonEnumeration в intellisense и появится что-то вроде 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
}

Компилятор С# довольно умный. Типы anon, созданные отдельно, будут иметь одинаковый сгенерированный тип, если их свойства совпадают.

Помимо этого, если у вас есть intellisense, имеет смысл использовать var в любом месте контекста.

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

Ответ 22

Я думаю, это зависит от вашей перспективы. Я лично никогда не испытывал затруднений с пониманием части кода из-за var "неправильного использования", и мои коллеги и я использую его довольно много. (Я согласен с тем, что Intellisense - огромная помощь в этом отношении.) Я приветствую это как способ устранить повторяющийся рывок.

В конце концов, если такие выражения, как

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

действительно невозможно было справиться, никто не использовал бы динамически типизированные языки.

Ответ 23

Я использую var только тогда, когда он очищается, чтобы узнать, какой тип используется.

Например, я бы использовал var в этом случае, потому что вы сразу увидите, что x будет иметь тип "MyClass":

var x = new MyClass();

Я бы не использовал var в таких случаях, потому что вам нужно перетащить мышь над кодом и посмотреть всплывающую подсказку, чтобы узнать, какой тип возвращает MyFunction:

var x = MyClass.MyFunction();

В частности, я никогда не использую var в случаях, когда правая сторона не является даже методом, а только значением:

var x = 5;

(потому что компилятор не может знать, хочу ли я байта, short, int или что-то еще)

Ответ 24

Для меня антипатия к var иллюстрирует важность двуязычия в .NET. Для тех программистов на С#, которые также сделали VB.NET, преимущества var интуитивно очевидны. Стандартное объявление С#:

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

является эквивалентом в VB.NET, набрав это:

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

Никто не делает этого в VB.NET. Было бы глупо, потому что с первой версии .NET вы смогли это сделать...

Dim whatever As New List(Of String)

... который создает переменную и инициализирует ее все в одной достаточно компактной строке. Ах, но что, если вы хотите IList<string>, а не List<string>? Ну, в VB.NET это означает, что вы должны это сделать:

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

Точно так же, как вам нужно было делать на С#, и, очевидно, не мог использовать var для:

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

Если вам нужен тип, чтобы быть чем-то другим, это может быть. Но одним из основных принципов хорошего программирования является сокращение избыточности и именно то, что делает var.

Ответ 25

Используйте его для анонимных типов - для чего он нужен. Что-нибудь еще используется слишком далеко. Как и многие люди, выросшие на C, я привык смотреть слева от объявления для типа. Я не смотрю на правую сторону, если только не придется. Использование var для любого старого объявления заставляет меня делать это все время, что лично мне неприятно.

Те, кто говорит: "Не важно, используйте то, что вам нравится" не видят всей картины. Каждый будет подбирать код других людей в какой-то момент и должен решать любые решения, принятые ими в момент их написания. Это достаточно плохо, чтобы иметь дело с радикально отличающимися соглашениями об именах, или - классическими стилями для стилизации рук, не добавляя в микс целую "var или нет". В худшем случае, когда один программист не использовал var, а затем приходит сопровождающий, который его любит, и расширяет код, используя его. Итак, теперь у вас есть нечестивый беспорядок.

Стандарты - это хорошая вещь именно потому, что они означают, что вы гораздо вероятнее сможете получить случайный код и сможете быстро его проверить. Чем больше вещей, чем другие, тем сложнее получается. И переход в стиль "var везде" делает разницу большой.

Я не возражаю против динамического ввода текста, и я не возражаю против ввода текста - на языках, которые предназначены для них. Мне очень нравится Python. Но С# был разработан как статически явно типизированный язык и как он должен оставаться. Нарушение правил для анонимных типов было достаточно плохим; позволяя людям воспринимать это еще дальше и сломать идиомы языка, еще больше - это то, чем я не доволен. Теперь, когда джинн выходит из бутылки, он никогда не вернется. С# станет балканизированным в лагеря. Нехорошо.

Ответ 26

Много раз во время тестирования я обнаружил, что имею такой код:

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

Теперь, иногда, я хочу посмотреть, что содержит SomeOtherThing, SomeOtherThing - это не тот тип, который возвращает CallMethod(). Так как я использую var, я просто изменяю это:

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

:

var something = myObject.SomeProperty.SomeOtherThing;

Без var мне придется продолжать изменять объявленный тип с левой стороны. Я знаю это незначительное, но это очень удобно.

Ответ 27

Для afficionados, которые считают, что var экономит время, требуется меньше клавиш:

StringBuilder sb = new StringBuilder();

чем

var sb = new StringBuilder();

Считайте em, если вы мне не верите...

19 против 21

Я объясню, нужно ли мне это делать, но просто попробуйте... (в зависимости от текущего состояния вашего intellisense вам, возможно, придется набрать еще пару для каждого)

И это верно для каждого типа, о котором вы можете думать!!

Мое личное чувство заключается в том, что var никогда не следует использовать, кроме случаев, когда тип неизвестен, поскольку он снижает узнаваемость readabiltiy в коде. Требуется мозг дольше, чтобы распознать тип, чем полная линия. Старые таймеры, которые понимают машинный код и биты, точно знают, о чем я говорю. Мозг работает параллельно, и когда вы используете var, вы вынуждаете его сериализовать свой вход. Почему кто-то хочет, чтобы их мозг работал сильнее? Для чего нужны компьютеры.

Ответ 28

Я разделяю var по всем местам, единственные сомнительные места для меня - внутренние короткие типы, например. Я предпочитаю int i = 3; более var i = 3;

Ответ 29

Это, безусловно, упростит, начиная с кода, который я написал вчера:

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

Это было бы очень многословно без var.

Добавление: небольшое время, проведенное с языком с реальным типом вывода (например, F #), покажет, насколько хорошие компиляторы получают правильное выражение типов выражений. Конечно, это означает, что я стараюсь использовать var насколько могу, и использование явного типа теперь указывает, что переменная не относится к типу инициализирующего выражения.