Просто любопытно. Я около 99.999% уверен, что нет... но что-нибудь?
РЕДАКТИРОВАТЬ: это ответы ОК (сохранение времени ввода или внесение кода менее подробным для "удобочитаемости" ). Думаю, я должен был бы уточнить, что я подразумевал под "использованием" - некоторой конструкцией/дизайном, которая не может быть выполнена без "var".
Что лучше с точки зрения удобочитаемости?
AReallyReallyLongBusinessObjectName obj = new AReallyReallyLongBusinessObjectName();
ИЛИ
var obj = new AReallyReallyLongBusinessObjectName();
Я говорю с точки зрения удобочитаемости, потому что использование var абсолютно не влияет на ваше приложение, поскольку два оператора генерируют один и тот же IL при компиляции.
Ответ на редактирование: нет ничего, что требует от вас использования var (кроме типов anon) - его просто синтаксического сахара.
Я использую его в циклах foreach очень часто:
foreach(var item in collection)
var в основном полезен для анонимных типов (вы не можете создать его без него). Я также видел, как другие используют его, чтобы уменьшить типизацию и избыточную информацию типа посредством вывода типа.
Я лично считаю, что это может ухудшить читаемость, когда оно используется для уменьшения набора текста - помните, что вы тратите 1% своего времени на создание кода и 99% времени на его чтение.
// the compiler may be able to infer the type
// of "foo" but I certainly cannot without
// viewing the implementation of "doSomething".
var foo = doSomething();
Изменить: Главное помнить (и это общепринято для всех вопросов стиля кодирования) заключается в том, что вам нужно выбрать стиль и использовать его последовательно. До тех пор, пока вам это нравится, и у вас есть причина использовать его, что вы чувствуете себя здорово, тогда вы выиграли битву:)
Я использую var все время - , особенно когда имя класса очень длинное.
Это не создает проблемы для меня, потому что мои методы обычно называются таким образом, что, просто взглянув на имя, я могу вывести тип.
И если я не могу, я буду использовать VS 2008 intellisense, чтобы помочь мне, или просто использую Resharper var = > конвертер имен классов, чтобы преобразовать его в явное имя.
Другой случай, который я нахожу большим использованием var, находится в цикле foreach:
foreach(var id in idList)
{
// do what you will here
}
Как насчет анонимных классов?
var mySomething = new { Name = "Hello", Age=12 };
Да, я использую его все время, создавая объекты для класса с длинным именем и в цикле foreach
РЕДАКТИРОВАТЬ: Я не думаю, что var может играть важную роль в дизайне или в любой конструкции... потому что его можно использовать только локально в рамках метода или в области видимости.
Другим важным ограничением var является то, что вы не можете использовать его как параметр метода или как тип возврата. Вы даже не можете объявить его полем в классе. Это означает, что мы можем использовать var, чтобы сохранить время ввода или сделать код менее подробным для "удобочитаемости" и с LINQ
Мое любимое использование не LINQ в сочетании с foreach. При указании типа явным образом инструктирует компилятор делать приведение, если это необходимо (что может привести к ошибке выполнения), а просто используя var - это простой способ убедиться, что у меня действительно есть тип элемента, который, я думаю, у меня есть.
Я нахожу его неоценимым в прототипировании, он позволяет мне быстро сохранять результаты из функций/свойств, а также позволяет мне впоследствии корректировать типы возвращаемых данных из этих функций с меньшей очисткой. Это (как wee) бит, как интерфейс для методов, он позволяет мне меньше беспокоиться о конкретных типах возврата и больше о намерении метода.
Как отмечали другие, это также полезно использовать при инициализации новых экземпляров объектов; с Foo foo = new Foo(); является избыточным. var foo = new Foo(); настолько читабельна, что даже лучше, если есть несколько объявлений...
var connString = BuildConnectionString();
var sqlConn = new SqlConnection(connString);
var commandText = BuildCommandText();
var sqlComm = new SqlCommand(commandText, sqlConn);
против.
string connString = BuildConnectionString();
SqlConnection sqlConn = new SqlConnection(connString);
string commandText = BuildCommandText();
SqlCommand sqlComm = new SqlCommand(commandText, sqlConn);
При использовании MVC и при наличии клиентского контроллера для возврата всех ваших запросов ajax, вы почти всегда будете использовать var, потому что с анонимным типом вы можете отправлять данные, необходимые приложению обратно клиенту, только для отправки.
var response = new { var1 = "bla", var2 = "foo" };
return JSon(response);
Я использую var почти для каждого присваивания локальной переменной. Это действительно ограничивает количество изменений кода, которые я должен выполнить, если изменяется тип возвращаемого метода. Например, если у меня есть следующий метод:
List<T> GetList()
{
return myList;
}
У меня могут быть строки кода по всему месту, выполняющие локальное назначение переменных, которые выглядят следующим образом:
List<T> list = GetList();
Если я изменю GetList(), чтобы вернуть IList <T> вместо этого я должен изменить все эти строки назначения. N строк присваивания равно N + 1, если я изменяю тип возврата.
IList<T> GetList()
{
return myList;
}
Если вместо этого я был закодирован следующим образом:
var list = GetList();
Затем мне нужно только изменить GetList(), а остальное будет проверено с помощью компиляции. Мы отключены и работаем только с одним изменением кода. Разумеется, компилятор будет жаловаться, если бы код в зависимости от списка был List <T> а не IList <T> ; но они должны быть меньше, чем N.
Я где-то читал, что рекомендуется использовать "var" в случаях, когда вы вызываете код в не написанном вами модуле, и который возвращает объект, тип которого подвержен будущим изменениям. Если вы должны были написать обертку к этому внешнему модулю, и вы только перешлите результат, чем использование var для временного хранения, ваш код останется действительным, если/когда тип данных, возвращаемый внешним вызовом, изменится. Кроме того, если вы знаете, что этот результат представляет собой какую-то коллекцию, но опять же, но не особенно стабильный, назначение var и последующее повторение могут все еще работать в случае дальнейших изменений.