Должен ли я * всегда * отдавать предпочтение неявно типизированным локальным переменным в C# 3.0?

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

Dooberry dooberry = new Dooberry();

к

var dooberry = new Dooberry();

Это действительно лучший стиль?

Ответов (12)

Решение

Это, конечно, вопрос стиля, но я согласен с Dare: неявные объявления типов в C# 3.0: использовать var или нет? . Я думаю, что использование var вместо явного типа делает ваш код менее читаемым. В следующем коде:

var result = GetUserID();

Каков результат? Интервал, строка, GUID? Да, это имеет значение, и нет, мне не нужно копаться в коде, чтобы узнать это. Особенно раздражает в примерах кода.

Джефф написал об этом сообщение, в котором говорится, что он отдает предпочтение var . Но этот парень сумасшедший!

Я вижу образец успеха stackoverflow: раскопайте старые сообщения CodingHorror и (в стиле Jeopardy) сформулируйте их в терминах вопроса.

@jongalloway - var не обязательно делает ваш код более нечитаемым.

var myvariable = DateTime.Now
DateTime myvariable = DateTime.Now;

Первый так же удобочитаем, как и второй, и требует меньше усилий.

var myvariable = ResultFromMethod();

Здесь вы понимаете, что var может сделать код менее читабельным. Мне нравится var, потому что если я изменю десятичное число на double, мне не придется менять его в нескольких местах (и не говорите рефакторинг, иногда я забываю, просто позвольте мне var!)

РЕДАКТИРОВАТЬ: просто прочтите статью, я согласен. ржу не могу.

Я вижу образец успеха stackoverflow: раскопайте старые сообщения CodingHorror и (в стиле Jeopardy) сформулируйте их в терминах вопроса.

Я не признаю своей невиновности! Но вы правы, этот вопрос казался относительно популярным.

«Лучший стиль» субъективен и варьируется в зависимости от контекста.

Иногда проще использовать var вместо того, чтобы вводить очень длинное имя класса, или если вы не уверены в типе возвращаемого значения данной функции. Я обнаружил, что использую 'var' чаще при работе с Linq или в объявлениях цикла.

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

Я чувствую, что решение должен принимать разработчик. Серебряной пули нет. Нет «единственно верного пути».

Ваше здоровье!

Это было хорошее обсуждение @ Coding Horror

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

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

Любой однострочный оператор, в котором имя типа может быть указано как для переменной, так и для ее значения, обязательно должен использовать var, особенно когда это длинный Generic <OtherGeneric <T, U, V>, Dictionary <X, Y >>>

Я чувствую, что это будет один из самых популярных вопросов, которые со временем задают на Stack Overflow. Все сводится к предпочтениям. Все, что вы думаете, более читабельно. Я предпочитаю var, когда тип определен справа, потому что он более краткий. Когда я назначаю переменную из вызова метода, я использую явное объявление типа.

Одним из преимуществ такого инструмента, как ReSharper, является то, что вы можете писать код, как вам нравится, а затем переформатировать его во что-то более удобное для обслуживания. У меня R # настроен на постоянное переформатирование, чтобы виден фактический используемый тип, однако при написании кода я почти всегда набираю var.

Хорошие инструменты позволят вам получить лучшее из обоих миров.

Джон.

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

Следующие ограничения применяются к объявлениям неявно типизированных переменных:

  • var может использоваться только тогда, когда локальная переменная объявляется и инициализируется в том же операторе; переменная не может быть инициализирована значением NULL, группой методов или анонимной функцией.
  • var не может использоваться в полях в области класса.
  • Переменные, объявленные с помощью var, нельзя использовать в выражении инициализации. Другими словами, это выражение допустимо: int i = (i = 20); но это выражение вызывает ошибку времени компиляции: var i = (i = 20);
  • Несколько неявно типизированных переменных не могут быть инициализированы в одном операторе.
  • Если тип с именем var находится в области видимости, то ключевое слово var будет преобразовано в это имя типа и не будет рассматриваться как часть объявления неявно типизированной локальной переменной.

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

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

мне ясно:

XmlNodeList itemList = rssNode.SelectNodes("item");
var rssItems = new RssItem[itemList.Count];

мне непонятно:

var itemList = rssNode.SelectNodes("item");
var rssItems = new RssItem[itemList.Count];

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

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

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

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

Это имеет смысл только тогда, когда вы заранее не знаете тип.