Почему var может быть плохим?

Авторы Руководства по проектированию .Net Framework (потрясающе book), вышедшие в ноябре 2008 г., рекомендуют рассмотреть возможность использования var, когда Тип очевиден и однозначен.

С другой стороны, если использование var приведет к неоднозначности при чтении кода, как указал Антон Гоголев, то лучше не использовать его.

в книге (приложение А) они фактически приводят такой пример:

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // Probably not good; it's not clear what the type of id is

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

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

var q = GetQValue();

это действительно плохо. Тем не мение,

var persistenceManager = ServiceLocator.Resolve<IPersistenceManager>();

меня совершенно устраивает.

Суть в следующем: используйте описательные имена идентификаторов, и все будет хорошо.

В качестве примечания: мне интересно, как они справляются с анонимными типами, когда им запрещено использовать ключевое слово var. Или вообще ими не пользуются?

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

Бывают случаи, когда неясно, что вы что-то сломали, изменив это - в основном, когда инициализированный тип и (исходный) тип переменной не совпадают, потому что:

• переменная изначально была базовым классом
• переменная изначально была интерфейсом
• переменная изначально была другого типа с неявным оператором преобразования

В этих случаях у вас могут возникнуть проблемы с любым разрешением типа, например:

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

В таких случаях вы меняете смысл кода и выполняете что-то другое. Тогда это плохо.

Примеры:

Неявное преобразование:

static void Main() {
    long x = 17;
    Foo(x);
    var y = 17;
    Foo(y); // boom
}
static void Foo(long value)
{ Console.WriteLine(value); }
static void Foo(int value) {
throw new NotImplementedException(); }

Скрытие метода:

static void Main() {
    Foo x = new Bar();
    x.Go();
    var y = new Bar();
    y.Go(); // boom
}
class Foo {
    public void Go() { Console.WriteLine("Hi"); }
}
class Bar : Foo {
    public new void Go() { throw new NotImplementedException(); }
}

и т.д

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

Не все корпоративные стандарты кодирования имеют смысл. Однажды я работал в компании, которая хотела добавить к имени компании префикс всех имен классов. Когда компания сменила название, произошла масштабная переделка.

Во-первых, как правило, стандарты кодирования должны обсуждаться и согласовываться командой, а их обоснование должно быть записано, чтобы каждый мог знать, для чего они существуют. Они не должны быть Святой Истиной от Единого Мастера.

Во-вторых, это правило, вероятно, оправдано, потому что код больше раз читается, чем пишется. var ускоряет запись, но может немного замедлить чтение. Очевидно, что это не правило поведения кода, такое как «Всегда инициализировать переменные», потому что две альтернативы (запись var и запись типа) имеют точно такое же поведение. Так что это не критическое правило. Я бы не стал запрещать var, я бы просто использовал "Предпочитаю ..."

Несколько месяцев назад я написал в блоге статью на эту тему. Что касается меня, я использую его везде, где это возможно, и специально разрабатываю свои API для вывода типов. Основные причины, по которым я использую вывод типов:

1. Это не снижает безопасность типов
2. Фактически это повысит безопасность типов в вашем коде, предупредив вас о неявном приведении типов. Лучший пример в инструкции foreach
3. Поддерживает принципы DRY в C #. Это специально для случая объявления, зачем говорить имя дважды?
4. В некоторых случаях это совершенно необходимо. Примеры анонимных типов
5. Меньше набора текста без потери функциональности.

http://blogs.msdn.com/jaredpar/archive/2008/09/09/when-to-use-type-inference.aspx.

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

Вашему другу просто не повезло, что они работают под одним из экстремистов.

Полный запрет означает запрет на использование анонимных типов (которые становятся невероятно полезными по мере того, как вы больше используете LINQ).

Это простая и понятная глупость, если только кто-то не может формализовать вескую причину никогда не использовать анонимные типы.

Что такое var на простом английском

Я собираюсь показать вам, что использование AND без использования var означает четкое общение.

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

Более того, вы увидите, насколько ясна 'var', во многом зависит от того, как вы называете все остальное в своем коде.

Возьмем этот пример:

Джейк поздоровался с Биллом. Он ему не понравился, поэтому он повернулся и пошел другой дорогой.

Кто пошел другой дорогой? Джейк или Билл? В этом случае «Джейк» и «Билл» похожи на название типа. А «Он» и «его» похожи на ключевое слово var. В этом случае было бы полезно уточнить детали. Следующий пример намного яснее.

Джейк поздоровался с Биллом. Джейку не понравился Билл, поэтому он повернулся и пошел другой дорогой.

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

Билл любит книги, поэтому Билл пошел в библиотеку, и Билл достал книгу, которая ему всегда нравилась.

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

Биллу нравятся книги, поэтому он пошел в библиотеку и достал книгу, которая ему всегда нравилась.

Эти аналогии охватывают суть, но не раскрывают всей истории. Видите ли, в этих примерах был только один способ обозначить человека. Либо своим именем, например Билл, либо более общим образом, например, «он» и «он». Но мы работаем только с одним словом.

В случае с кодом у вас есть два «слова»: тип и имя переменной.

Person p = GetPerson();

Теперь возникает вопрос: достаточно ли информации, чтобы вы могли легко определить, что такое p? Вы все еще знаете, какие люди в этом сценарии:

var p = GetPerson();

Как насчет этого:

var p = Get();

Как насчет этого:

var person = Get();

Или вот этот:

var t = GetPerson();

Или вот этот:

var u = Person.Get();

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

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

Тем не менее, иногда я делаю исключения, такова природа чего-либо сложного, а программное обеспечение - ничто иное, как сложное.

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

Вы можете считать мнение Microsoft актуальным, поскольку C # - их язык:

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

См. MSDN - неявно типизированные локальные переменные (программирование на C # Руководство), последний абзац.

Вы также должны знать, что var удаляет проверку типа данных во время компиляции при начальном назначении.

var x = "mistake";     // error not found by compiler
int x = "mistake";     // error found

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

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

Это действительно проблема с читабельностью вашего кода.

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

Однако C # 3.0 с радостью позволит вам использовать var где угодно, кроме LINQ и анонимных типов, например:

var myint = 0;
var mystring = "";

совершенно корректно, а myint и mystring будут строго типизированы по предполагаемым значениям, используемым для их инициализации. (таким образом, myint - это System.Int32, а mystring - это System.String). Конечно, довольно очевидно, если посмотреть на значения, используемые для инициализации переменных, к каким типам они будут неявно типизированы, однако я думаю, что для читабельности кода было бы даже лучше, если бы приведенное выше было написано как:

int myint = 0;
string mystring = "";

так как вы можете сразу увидеть, к какому типу относятся эти переменные.

Рассмотрим этот несколько сбивающий с толку сценарий:

var aaa = 0;
double bbb = 0;

Совершенно правильный код (если немного нетрадиционный), но в приведенном выше примере я знаю, что bbb является двойным, несмотря на то, что инициализирующее значение выглядит как int, но aaa определенно будет не двойным, а скорее int.

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

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

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

Эрик Липперт, суммы это хорошо:

• При необходимости используйте var; когда вы используете анонимные типы.
• Используйте var, когда тип объявления очевиден из инициализатора, особенно если это создание объекта. Это устраняет избыточность.
• Рассмотрите возможность использования var, если код подчеркивает семантическую «бизнес-цель» переменной и преуменьшает «механические» детали ее хранения.
• Используйте явные типы, если это необходимо для правильного понимания и поддержки кода.
• Используйте описательные имена переменных независимо от того, используете ли вы «var». Имена переменных должны отражать семантику переменной, а не детали ее хранения; «decimalRate» - это плохо; "InterestRate" - это хорошо.

Мое собственное мнение: мне труднее читать и немного бессмысленно с такими типами, как int, string, bool или даже User. В конце концов, речь идет о удобочитаемости (кроме случаев, когда его используют с LINQ), поэтому, когда вары разбросаны, может быть труднее прочитать и победить цель ключевого слова, для которой разработчики языка предусмотрели его.

Из Департамента избыточности деклараций (из Джеффа Coding Horror):

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

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

У меня были случаи (когда я выполнял foreach через коллекцию Table.Rows), когда использование var приводило к тому, что тип принадлежал к некоторому базовому классу, а не к фактическому типу DataRow. Это единственный раз, когда у меня были проблемы с var.

Вот результаты проведенного мной теста на эффективность var по сравнению с явной типизацией:

  private void btnVar_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        var test = "Test";
        test.GetType();
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();
    }

    private void btnString_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        string test = "Test";
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();

    }

Результат первого ярлыка: 00:00:00 000034

Результат второй метки: 00:00:00 00008