Это отличный вопрос для начинающего разработчика. Не обязательно, чтобы спрашивающий был младшим, но что обеспечение разъяснения перед представлением информации младшему разработчику - отличная вещь.
В этом духе, кто бы ни находил этот вопрос, всегда должен понимать, что удобочитаемость является одним из немногих атрибутов качества и, безусловно, одним из самых важных для овладения на раннем этапе. Читаемость включает в себя методы именования переменных и явный код, чтобы назвать пару.
Тем не менее, один отдельный микро-аспект читабельности заключается в том, следует ли использовать неявную типизацию через ключевое слово var. Краткий ответ: Может быть . Образованный ответ с примерами может сузить Возможно до Редко .
Итак, чтобы сделать это проще для понимания, я начну с причин , а не , чтобы использовать простоту при вводе с помощью ключевого слова var.
(Перспектива языка) Первая причина не использовать неявную типизацию заключается в том, что основной сильной стороной C # является то, что это язык со строгой типизацией. Есть много замечательных языков, сильные стороны которых не включают в себя строгую типизацию, например, Javascript. Каждый язык отличается и имеет свои сильные и слабые стороны. Для C # сильная типизация является одной из его самых сильных сторон.
В этом ответе предполагается, что ваш код является ТВЕРДЫМ. Если вы работаете в унаследованной кодовой базе или являетесь младшим разработчиком, который еще не полностью сфокусировался на внедрении зависимостей или замене Liskov, то микро-настройка вашего использования var находится не там, где вы должны сосредоточиться прямо сейчас .
Существует только несколько способов присвоения переменной. Вот те, о которых я думаю сейчас:
ISomething someVar = new Concrete(); // <1. Can't use var to create Interfaces.
var someVar = GetFromMethod(); // <-- 2. Taken from return type
var someVar = new MyPerson(); // <-- 3. Custom complex reference type
var someVar = new DateTime(); // <-- 4. Built-in simple Reference Type
var someVar = string.Empty; // <-- <<
var someVar = new List<T>(); // <-- 5. Built-in complex Reference Type
var someVar = new Dictionary<string, Dictionary<int, List<MyObject>>>();
var someVar = true; // <-- 6. simple Value type assignment
var someVar = 1; // <-- 7. complex Value type assignment(s)
var someVar = 1.0; // <-- <<
var someVar = 1.0d; // <-- <<
foreach (var i = 0; i <= . . .) // <-- 8. Same as 7 above, but different context.
var someVar = new {Name = "yo"}; // <-- 9. Instantiate Anonymous Type
(Breakdown)
1. В примере 1 из приведенных выше примеров я иллюстрирую единственный случай, когда вы просто не можете использовать ключевое слово var. Вы, очевидно, не можете создать конкретную реализацию в интерфейсе. Я подробнее расскажу об использовании интерфейсов в # 5. Не Здесь нельзя использовать var
2. В примере 2 предполагается, что кто-то использует те же инструменты разработки, что и вы, и что каждый хочет потратить время на чтение кода, чтобы исследовать методы возвращаемого типа. В зависимости от того, насколько быстро вы читаете код или обзор кода, это может быть незначительным или серьезным недостатком. Не используйте var здесь
3. Почему вы создаете новую версию in-line? Как я уже говорил ранее, эти примеры предполагают, что вы практикуете принципы SOLID. Этот способ объявления переменной создает запах кода. Если вы выполняете поиск по своей базе кода по ключевому слову new, единственными результатами должны быть автоматически сгенерированный код, корень композиции или номер 4 ниже. Не используйте var здесь никогда не делайте этого
4. new DateTime(); и пара других редких встроенных простых типов - это те редкие случаи, когда вы должны видеть ключевое слово new в своей кодовой базе. Использование ключевого слова var в примере 4 не так уж сложно. Но, честно говоря, что вы покупаете, сражаясь, чтобы быть скрытым в этой ситуации? Тот же вопрос для строки. Здесь можно использовать var ... но почему?
5. Вы всегда должны стараться использовать наименее конкретный возможный тип. Короче говоря, это означает использование небольших интерфейсов. Это правило в основном применяется к внешним API-интерфейсам, потому что вы хотите, чтобы изменения были максимально гибкими, не нарушая потребителя. Единственная причина, по которой это правило НЕ строго применяется к внутреннему коду, потому что, если разработчик хочет внести критическое изменение, он может потратить дополнительное время и выполнить дополнительную работу для каскадного исправления ошибок. Это не очень хорошее оправдание.
..... 5.1 Итак, для первой части обратите внимание, что someVar становится типом Generic.List<T>. Если вы хотите создать переменную типа IList, как вы можете видеть, тогда использование ключевого слова var не то, что вам нужно. Как правило, это правило для объявления переменных с наименьшим возможным типом. Посмотрите на: IList против Список . Что если вы намеренно не хотите, чтобы использование вашей переменной включало весь этот дополнительный мусор в List<T>? Есть причина для этих правил. Старайтесь не использовать ключевое слово var, если вы можете следовать этому правилу.
..... 5.2 Предполагая, что вам все равно или вы не хотите использовать интерфейсы в соответствии с рекомендациями, это нормально. Это также в некоторой степени относится к идее длины. Если у вас есть вложенные уровни коллекций и ваше объявление длинное, никто не будет винить вас за использование ключевого слова var. Хорошо, если вы не используете интерфейсы
6. Это похоже на пример # 7, но применяется к нечисловым типам значений. Простой вопрос: «Почему?» Как я уже сказал в # 4, что вы покупаете? Предполагая, что вы используете значение по умолчанию, вам все равно придется указать тип. Зачем смешивать правила, и что он покупает? Конечно, но почему?
Э.Г .: Вы все равно должны быть иногда явными, зачем смешивать правила?:
bool isVarOkay, canUseVar;
char a, b, c, d, e, f;
bool isSample = true;
byte etc;
var isOtherSample = true; //<-- why?
7. Существует множество типов числовых значений. Большинство рассуждений об этом для точности, а некоторые для семантических целей. В любом случае, почему бы компилятору угадать, что вы хотите, а не явно. Если когда-либо было явное время, типы числовых значений - это время. Что касается обычного int, возможно, есть некоторая возможность использовать var, так как он настолько прямой и очевидный. Но я бы предпочел сохранить это для пункта № 8. Не используйте ключевое слово var
8. Эта структура кода используется во многих местах, так что кажется, что это почти нормально. Но еще раз: почему и что вы экономите? var и int - 3 символа. Конечно, но почему?
9. В случае анонимных возвратов вам почти необходимо использовать ключевое слово var. Не делать такого рода поражений с целью быть анонимным. Большинство анонимных типов могут быть встроены так, что их результаты немедленно превращаются во что-то полезное, поэтому их не обязательно присваивать переменной. Но есть несколько поводов для этого, которых не стоит избегать. При необходимости используйте var для анонимных типов.
Заключение
Ключевое слово var неизбежно для анонимных типов. Кроме того, это может быть полезно для универсальных типов с несколькими уровнями универсальных шаблонов, которые делают длинное объявление, как пример Дмитрия Dictionary<string, Dictionary<int, List<MyObject>>>. Наконец, никому не повредит чувства, если вы используете ключевое слово var в примерах, показанных в числах 4, 5, 6 и 8. Но вы ничего не покупаете.
Идея о том, что использование ключевого слова var позволяет изменить тип или придерживаться принципа СУХОЙ, является не чем иным, как ложным оправданием. Только в редких случаях Сторона назначения объявления правильно представляет собой то, чем должен быть Тип.