Что использовать: var или тип имени объекта? [дубликат]
8 ответов
Вне очевидного использования var с LINQ, я также использую его для сокращения волосатых объявлений переменной для удобочитаемости, например:
var d = new Dictionary<string, Dictionary<string, Queue<SomeClass>>>();
В целом, я получаю своего рода комфорт (из-за отсутствия лучшего слова) от статического контроля типов, который делает меня отказывающимся бросить его. Мне нравится чувство, что я знаю то, что я делаю, когда я объявляю переменную. Объявление переменной только говорит компилятору что-то, это говорит человеку, читающему Ваш код что-то.
Позволяют мне дать Вам пример. Предположим, что у меня есть метод, который возвращается List<string>. Этот код, конечно, корректен, и я думаю, что это - как 90% разработчиков C#, вероятно, записали бы его:
List<string> list = MyMethod();
, Очевидно, правильно? На самом деле вот место, которое Вы могли так же, как легко использовать var.
Достаточно верный. Но этот версия кода только объявляет переменную, это говорит мне, что человек, который записал его, намеревается сделать:
IEnumerable<string> list = MyMethod();
разработчик, который записал, что код говорит мне, "я не собираюсь быть изменением этого списка, и при этом я не собираюсь использовать индекс для доступа к его участникам. Все, что я собираюсь сделать, выполняют итерации через него". Это - большая информация для объяснения в одной строке кода. Это - что-то, что Вы бросаете, если Вы используете var.
, Конечно, Вы не бросаете его, если Вы не использовали его во-первых. Если бы Вы - вид разработчика, который записал бы, что строка кода, Вы уже знаете, что не использовали бы var там.
Редактирование:
я просто перечитал сообщение Jon Skeet, и эта кавычка от Eric Lippert выскочила во мне:
Неявно введенные местные жители являются всего одним маленьким путем, которым можно преуменьшить роль, как и таким образом подчеркивают какой.
я думаю, что на самом деле в большом количестве случаев с помощью неявной типизации уезжает какой неявный. Нормально просто не останавливаться какой. Например, я небрежно запишу запрос LINQ как:
var rows = from DataRow r in parentRow.GetChildRows(myRelation)
where r.Field<bool>("Flag")
orderby r.Field<int>("SortKey")
select r;
, Когда я считал тот код, одну из вещей, я думаю, когда я читаю, это" rows, IEnumerable<DataRow>". Поскольку я знаю, что, что возврат запросов LINQ IEnumerable<T>, и я вижу тип объекта, выбираемого тут же.
Это - случай, где, что не имеет сделанный явным. Это было оставлено для меня для выведения.
Теперь, приблизительно в 90% случаев, где я использую LINQ, это не имеет значения одно крошечное немного. Поскольку 90% времени, следующая строка кода:
foreach (DataRow r in rows)
, Но не трудно предположить код, в котором было бы очень полезно объявить rows как [1 114] - код, где много различных видов объектов запрашивалось, не было выполнимо поместить объявление запроса рядом с повторением, и будет полезно быть в состоянии, осматривают rows с IntelliSense. И это какой вещь, не как вещь.
Вы получите огромное множество мнений об этом - от "var использования везде" к "только var использования с анонимными типами, где Вы в основном имеете к". Мне нравится , Eric Lippert берет его :
Весь код является абстракцией. То, что код является “really”, делающим, управляет данными? Нет. Числа? Биты? Нет. Напряжения? Нет. Электроны? Да, но понимание кода на уровне электронов является плохой идеей! Искусство кодирования выясняет то, что правильный уровень абстракции для аудитории.
На высокоуровневом языке всегда существует эта сила между тем, ЧТО код делает (семантически) и КАК код выполняет его. Программисты обслуживания должны понять и какой и как если they’re, собирающийся быть успешным во внесении изменений.
смысл LINQ - то, что он в широком масштабе преуменьшает роль, "как" и в широком масштабе подчеркивает "какой". При помощи понимания запроса программист говорит будущей аудитории, "Я полагаю, что Вы не должны ни знать, ни заботиться точно, как этот набор результатов вычисляется, но необходимо заботиться очень о том, какой семантика получающегося набора". Они делают код ближе к бизнес-процессу реализованным и дальше от битов и электронов, которые заставляют его пойти.
Неявно введенные местные жители являются всего одним маленьким путем, которым можно преуменьшить роль, как и таким образом подчеркивают какой. Является ли это правильным поступком в особом случае, личный выбор. Таким образом, я говорю людям, что, если знание типа релевантно и его выбор крайне важен для длительной операции метода, то не используйте неявную типизацию. Явная типизация говорит, что "Я говорю Вам, как это работает по причине, обратите внимание". Неявная типизация говорит "это, doesn’t имеют значение немного, является ли этой вещью Список или Клиент [], что имеет значение, то, что это - набор клиентов".
Лично я не делаю , склоняются для использования его, если тип не довольно очевиден - где я включаю запросы LINQ, как являющиеся "довольно очевидным". Я не сделал бы этого для Directory.GetFiles, например, поскольку не действительно очевидно, что это возвращается string[] вместо (говорят) FileInfo[] (или что-то еще полностью) - и который имеет большое значение к тому, что Вы делаете позже.
, Если существует вызов конструктора на правой стороне оператора присваивания, я, намного более вероятно, пойду с var: очевидно очевидно, каков тип будет. Это особенно удобно со сложными универсальными типами, например, Dictionary<string,List<int>>.
Лично я только использую var в двух местах:
- С анонимными типами, т.е. LINQ-связанный (где var требуется в некоторых случаях)
- , Когда оператор объявляет и создает определенный тип в том же типе
т.е. это - пример точки 2:
var names = new List<String>();
Отредактированный : Это в ответ на вопрос Jon Skeet.
вышеупомянутый ответ был на самом деле упрощен. В основном я использую var, где тип также:
- Ненужный для знания (не, что много мест, хотя)
- Невозможный знать (LINQ, анонимные типы)
- Иначе известный или ясный из кода
В случае метода фабрики, где все необходимо знать в месте, где Вы пишете, код - то, что объект, который Вы возвращаете, является потомком некоторого типа, и что некоторый тип имеет статический метод фабрики, тогда я использовал бы var. Как это:
var connection = DatabaseConnection.CreateFromConnectionString("...");
вышеупомянутым примером является реальный пример от моего кода. Это ясно, по крайней мере, мне и людям, которые используют этот код, тот , соединение является потомком DatabaseConnection, но точный тип не не нужен ни для понимания кода, ни для использования его.
Я попробовал "var использования везде" стиль... и здесь - почему я не продолжал использовать его.
- Ухудшенная удобочитаемость время от времени
- Пределы Intellisense после =
- Ввод "var" действительно не был намного короче, чем ввод "интервала", "строки", и т.д., особенно с intellisense.
После этих слов я ДЕЙСТВИТЕЛЬНО все еще использую его с LINQ.
Приезжая из земли функционального программирования, где вывод типа управляет днем, я использую var для всех местных жителей по мере возможности.
В Visual Studio, если Вы когда-либо задаетесь вопросом, каков тип любого локального, все, которое необходимо сделать, нависнуть над ним с мышью.
Этот сообщение имеет некоторые хорошие инструкции по тому, когда использовать интерфейс типа var или типы объектов.
Я склонен использовать var везде, но мои коллеги сказали "стоп", это менее читаемо нам. Так я теперь я использую var только на анонимных типах, запросах LINQ и где конструктор на правой стороне.
Я думаю, что интересно отметить, как это обычно обрабатывается в Haskell. Благодаря Изоморфизм Карри-Говарда , может быть выведен (самый общий) тип любого выражения в Haskell, и таким образом описания типа по существу не требуются нигде за немногим исключением; например, иногда Вы сознательно хотите ограничить тип чем-то более определенным, чем было бы выведено.
, Конечно, что требуется и что рекомендуется, не то же самое; на практике соглашение, кажется, что определения верхнего уровня всегда имеют описания типа, в то время как локализованным определениям не учли описания типа. Это, кажется, устанавливает хорошее равновесие между явностью для удобочитаемости определения в целом, контрастировавший с краткостью для удобочитаемости локального "помощника" или "временных" определений. Если я понимаю правильно, Вы не можете использовать var для определений "верхнего уровня" (как метод или глобальная функция) во-первых, таким образом, я предполагаю, что это переводит для "использования var везде, Вы можете" в мире C#. Конечно, ввод" int" является тем же количеством нажатий клавиш как" var", но большинство примеров будет более длительным, чем это.