Вопрос

После обсуждения с коллегами относительно использования ключевого слова 'var' в C # 3 мне стало интересно, каковы мнения людей о подходящем использовании вывода типов через var?

Например, я довольно лениво использовал var в сомнительных обстоятельствах, например:-

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

Более законными видами использования var являются следующие:-

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

Интересно, что LINQ, похоже, является немного серой областью, например:-

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

Понятно, к каким результатам приведет то, что это будет тип, который реализует IEnumerable , однако это не совсем очевидно так же, как var, объявляющий новый объект.

Это еще хуже, когда дело доходит до LINQ для объектов, например:-

var results = from item in someList
              where item != 3
              select item;

Это ничем не лучше, чем эквивалентный foreach(элемент var в someList) { // ...} эквивалентно.

Здесь возникает реальная проблема безопасности типов - например, если бы мы поместили результаты этого запроса в перегруженный метод, который принимал IEnumerable<int> и IEnumerable<double> вызывающий может непреднамеренно ввести неправильный тип.

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

Это было полезно?

Решение

Я все еще думаю, что var может сделать код более читабельным в некоторых случаях. Если у меня есть класс Customer со свойством Orders, и я хочу присвоить его переменной, я просто сделаю это:

var orders = cust.Orders;

Мне все равно, является ли Customer.Orders IEnumerable < Order > , ObservableCollection < Order > или BindingList < Order > - все Я хочу, чтобы сохранить этот список в памяти, чтобы перебрать его или получить его счет или что-то позже.

Сравните приведенную выше декларацию с:

ObservableCollection<Order> orders = cust.Orders;

Для меня имя типа просто шум. И если я вернусь и решу изменить тип Customer.Orders в дальнейшем (скажем, с ObservableCollection < Order > на IList < Order > ), тогда мне нужно измените и эту декларацию - что-то, что мне не пришлось бы делать, если бы я сначала использовал var.

Другие советы

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

Правда, это может означать, что не ясно, с каким типом мы имеем дело. И что? Это на самом деле точка развязанного дизайна. При работе с интерфейсами вы не заинтересованы в том, какой тип имеет переменная. var делает это намного дальше, правда, но я думаю, что аргумент остается неизменным с точки зрения читабельности: программист должен интересоваться не типом переменной, а тем, что переменная делает . Вот почему Microsoft также вызывает вывод типа & # 8220; типизирование утки. & # 8221;

Итак, что делает переменная, когда я объявляю ее с помощью var ? Легко, он делает то, что мне подсказывает IntelliSense. Любые рассуждения о C #, которые игнорируют IDE, не соответствуют действительности. На практике каждый код C # программируется в среде IDE, которая поддерживает IntelliSense.

Если я использую объявленную переменную var и запутываюсь, для чего эта переменная, в моем коде что-то в корне неверное. var - это не причина, а только симптомы. Не вините посланника.

Теперь команда C # выпустила руководство по кодированию, в котором говорится, что var должен only использоваться для захвата результата оператора LINQ, который создает анонимный тип (потому что здесь У нас нет реальной альтернативы var ). Ну, винт это. Пока команда C # не дает мне веских аргументов в пользу этого руководства, я буду игнорировать его, потому что, по моему профессиональному и личному мнению, это чистый вздор. (Извините, у меня нет ссылки на данный вопрос.)

На самом деле, есть (внешне) хорошие объяснения почему вы не должны использовать var , но я все еще считаю, что они в значительной степени ошибочны. Возьмем пример & # 8220; searchabililty & # 8221 ;: автор утверждает, что var затрудняет поиск мест, где используется MyType . Правильно. Так же как и интерфейсы. На самом деле, почему я хотел бы знать, где используется класс? Возможно, меня больше интересует, где он создается, и он все равно будет доступен для поиска, потому что где-то должен вызываться его конструктор (даже если это делается косвенно, имя типа должно упоминаться где-то).

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

С моей точки зрения, использование хороших соглашений об именовании переменных и методов более важно с точки зрения удобства чтения, чем явная информация о типе.Если мне нужна информация о типе, я всегда могу навести курсор на переменную (в VS) и получить ее.Однако, как правило, явная информация о типе не должна быть необходимой читателю.Для разработчика в VS вы по-прежнему получаете Intellisense, независимо от того, как объявлена переменная.Сказав все это, все еще могут быть случаи, когда имеет смысл явно объявлять тип - возможно, у вас есть метод, который возвращает List<T>, но вы хотите относиться к этому как к IEnumerable<T> в вашем методе.Чтобы убедиться, что вы используете интерфейс, объявление переменной типа interface может сделать это явным.Или, возможно, вы хотите объявить переменную без начального значения - потому что она немедленно получает значение на основе некоторого условия.В этом случае вам нужен тип.Если информация о типе полезна или необходима, продолжайте и используйте ее.Однако я чувствую, что обычно в этом нет необходимости, и в большинстве случаев код легче читать без него.

Ни один из них не является абсолютно верным; var может оказывать как положительное, так и отрицательное влияние на читаемость. По моему мнению, var следует использовать, когда выполняется одно из следующих условий:

<Ол>
  • Тип является анонимным (ну, здесь у вас нет выбора, так как в этом случае он должен быть var)
  • Тип очевиден в зависимости от назначенного выражения (то есть var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating () )
  • var не влияет на производительность, так как это синтаксический сахар; компилятор выводит тип и определяет его, как только он скомпилирован в IL; в этом нет ничего на самом деле динамического.

    От Эрика Липперта, старшего инженера-разработчика программного обеспечения в команде C #:

    Почему было введено ключевое слово var ?

      

    Есть две причины, одна из которых   существует сегодня, тот, который возникнет   в 3.0.

         

    Первая причина в том, что этот код   невероятно некрасиво из-за всех   избыточность:

         

    Словарь < строка, список < int > > mylists = new Dictionary < string, List < int > > ();

         

    И это простой пример & # 8211; Я   написано хуже. В любое время вы вынуждены   набрать одно и то же дважды,   это избыточность, которую мы можем   Удалить. Намного приятнее писать

         

    var mylists = new Dictionary < string, List < int > > ();

         

    и пусть компилятор выяснит, что   тип основан на присваивании.

         

    Во-вторых, C # 3.0 вводит анонимно   типы. Поскольку анонимные типы   определение не имеет имен, вам нужно   быть в состоянии вывести тип   переменная из инициализации   выражение, если его тип анонимный.

    Акцент мой. Вся статья, C # 3.0 по-прежнему статически типизирован, честно! и последующее серия довольно хорошая.

    Это то, для чего var . Другое использование, вероятно, не будет работать так хорошо. Любое сравнение с JScript, VBScript или динамической типизацией является полной накладкой. Обратите внимание, что var является обязательным , чтобы некоторые другие функции работали в .NET.

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

    У меня нет проблем с использованием var в выражении foreach при условии, что это не так:

    foreach (var c in list) { ... }
    

    Если бы это было больше так:

    foreach (var customer in list) { ... }
    

    ... тогда кто-то, читающий код, с большей вероятностью поймет, что такое "список" является. Если у вас есть контроль над именем самой переменной списка, это даже лучше.

    То же самое можно применить к другим ситуациям. Это довольно бесполезно:

    var x = SaveFoo(foo);
    

    ... но это имеет смысл:

    var saveSucceeded = SaveFoo(foo);
    

    Думаю, каждому свое. Я обнаружил, что делаю это, что просто безумие:

    var f = (float)3;
    

    Мне нужна какая-то 12-шаговая вар-программа. Меня зовут Мэтт, и я (ab) использую var.

    Мы приняли принцип "Код для людей, а не для машин", основанный на предположении, что вы тратите в режиме обслуживания в несколько раз больше времени, чем на новую разработку.

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

    Таким образом,

    var something = SomeMethod();
    

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

    var list = new List<KeyValuePair<string, double>>();
    FillList( list );
    foreach( var item in list ) {
       DoWork( item ); 
    }
    

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

    Еще один случай, вызывающий озабоченность, в следующем вызове вы не можете определить, просто посмотрев на код, тип, возвращаемый CallMe :

    var variable = CallMe();
    

    Это моя главная жалоба на вар.

    Я использую var, когда объявляю анонимные делегаты в методах, как-то var выглядит чище, чем если бы я использовал Func . Рассмотрим этот код:

    var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
       ...
    });
    

    РЕДАКТИРОВАТЬ : обновил последний пример кода на основе ввода Джулиана

    Var совсем не похож на вариант. Переменная все еще строго типизирована, просто вы не нажимаете клавиши, чтобы получить ее таким образом. Вы можете навести на него курсор в Visual Studio, чтобы увидеть тип. Если вы читаете напечатанный код, возможно, вам придется немного подумать, чтобы понять, что это за тип. Но есть только одна строка, которая объявляет это, и много строк, которые его используют, поэтому присвоение приличных имен по-прежнему является лучшим способом облегчить выполнение вашего кода.

    Использование Intellisense лениво? Он меньше печатает, чем целое имя. Или есть вещи, которые меньше работают, но не заслуживают критики? Я думаю, что есть, и Вар является одним из них.

    Наиболее вероятный случай, когда вам это понадобится, - для анонимных типов (где это требуется на 100%).;но это также позволяет избежать повторения в тривиальных случаях, и IMO делает линию более четкой.Мне не нужно видеть тип дважды для простой инициализации.

    Например:

    Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();
    

    (пожалуйста, не редактируйте hscroll в приведенном выше - это как бы доказывает суть !!!)

    против:

    var data = new Dictionary<string, List<SomeComplexType<int>>>();
    

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

    static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
    static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}
    
    // this working code...
    IFoo oldCode = new Foo();
    DoSomething(oldCode);
    // ...is **very** different to this code
    var newCode = new Foo();
    DoSomething(newCode);
    

    Один конкретный случай, когда var сложен: проверка автономного кода, особенно те, которые сделаны на бумаге.

    Вы не можете полагаться на наведение мыши для этого.

    Я не понимаю, в чем дело ..

    var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!
    

    У вас все еще есть полный смысл на что-то, и для любого неоднозначного случая у вас есть свои юнит-тесты, верно? (ты?)

    Это не varchar, это не тусклый, и, конечно, это не динамическая или слабая типизация. Это останавливает maddnes как это:

    List<somethinglongtypename> v = new List<somethinglongtypename>();
    

    и уменьшая этот общий беспорядок до:

    var v = new List<somethinglongtypename>();
    

    Хорошо, не так хорошо, как:

    v = List<somethinglongtypename>();
    

    Но тогда это то, что .

    Если кто-то использует var ключевое слово, потому что они не хотят "определять тип", это определенно неправильная причина.Тот Самый var ключевое слово не создает переменную с динамическим типом, компилятор все равно должен знать этот тип.Поскольку переменная всегда имеет определенный тип, этот тип также должен быть очевиден в коде, если это возможно.

    Веские причины для использования var ключевыми словами являются, например:

    • Там, где это необходимо, т.е.чтобы объявить ссылку для анонимного типа.
    • Где это делает код более читаемым, т.е.удаление повторяющихся объявлений.

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

    Учитывая, насколько мощным теперь является Intellisense, я не уверен, что var сложнее для чтения, чем наличие переменных-членов в классе или локальных переменных в методе, которые определены вне видимой области экрана.

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

    IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
    

    Это намного легче или труднее читать, чем:

    var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();
    

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

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

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

    Другая вещь, которую следует помнить, это то, что это не VB-тип var в том смысле, что он не может изменять типы - это является строго типизированная переменная - это просто вывод типа (вот почему есть люди, которые будут утверждать, что вполне разумно использовать ее, скажем, в foreach, но я бы не согласился по причинам как удобочитаемости, так и ремонтопригодности).

    Я подозреваю, что этот будет бегать и бегать (-:

    Мерф

    Конечно, int легко, но когда тип переменной равен IEnumerable < MyStupidLongNamedGenericClass < int, string > > <> code>, var делает вещи намного проще.

    Украдено из сообщения об этой проблеме в CodingHorror :

    <Ч>

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

    MyObject m = new ();

    Или если вы передаете параметры:

    Person p = new ("FirstName", "LastName);

    Где при создании нового объекта компилятор выводит тип с левой стороны, а не справа. Это имеет другие преимущества по сравнению с «var», в том смысле, что его можно использовать и в объявлениях полей (есть также некоторые другие области, которые могут быть полезны, но я не буду вдаваться в подробности).

    В конце концов, это просто не было предназначено для уменьшения избыточности. Не поймите меня неправильно, " var " это ОЧЕНЬ важно в C # для анонимных типов / проекций, но использование здесь просто ОТКЛЮЧЕНО (и я говорил это очень долго), когда вы запутываете используемый тип. Потребность дважды напечатать это слишком часто, но объявлять его нулем - слишком мало.

    Николас Палдино .NET / C # MVP 20 июня 2008 г., 08:00

    <Ч>

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

    Если вы собираетесь когда-либо быть человеком, который просматривает ваш код, то кого это волнует? В противном случае, в таком случае:

    var people = Managers.People
    

    это нормально, но в таком случае:

    var fc = Factory.Run();
    

    он замыкает любые непосредственные выводы типа, которые мой мозг может начать формировать из «английского» кода.

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

    Использование var вместо явного типа значительно упрощает рефакторинг (поэтому я должен противоречить предыдущим постерам, которые имели в виду, что это не имеет значения, или это был просто "синтаксический сахар").

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

    ...
    List<MyClass> SomeMethod() { ... }
    ...
    

    который используется как

    ...
    IList<MyClass> list = obj.SomeMethod();
    foreach (MyClass c in list)
      System.Console.WriteLine(c.ToString());
    ...
    

    Если вы хотите провести рефакторинг SomeMethod () , чтобы он возвращал IEnumerable < MySecondClass > , вам придется изменить объявление переменной (также внутри foreach ) в каждом месте, где вы использовали метод.

    Если вы напишите

    ...
    var list = obj.SomeMethod();
    foreach (var element in list)
      System.Console.WriteLine(element.ToString());
    ...
    

    Вместо этого вам не нужно его менять.

    @aku: Одним из примеров являются обзоры кода. Другой пример - сценарии рефакторинга.

    По сути, я не хочу охотиться за типами с помощью мыши. Это может быть недоступно.

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

    C # var довольно круто в том смысле, что он выглядит как динамическая типизация, но на самом деле это статическая типизация - компилятор обеспечивает правильное использование.

    Тип вашей переменной не так уж важен (об этом уже говорилось). Это должно быть относительно ясно из контекста (его взаимодействия с другими переменными и методами) и его имени - не ожидайте, что customerList будет содержать int ...

    Я все еще жду, чтобы узнать, что мой босс думает по этому вопросу - у меня есть одеяло "Вперед" использовать любые новые конструкции в 3.5, но что мы будем делать с обслуживанием?

    При сравнении IEnumerable < int > и IEnumerable < double > вам не нужно беспокоиться - если вы передадите неправильный тип, ваш код не скомпилируется в любом случае.

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

    Var абсолютно необходим для Linq:

    var anonEnumeration =
        from post in AllPosts()
        where post.Date > oldDate
        let author = GetAuthor( post.AuthorId )
        select new { 
            PostName = post.Name, 
            post.Date, 
            AuthorName = author.Name
        };
    

    Теперь посмотрите на anonEnumeration в intellisense, и он будет выглядеть примерно так: IEnumerable < 'a >

    foreach( var item in anonEnumeration ) 
    {
        //VS knows the type
        item.PostName; //you'll get intellisense here
    
        //you still have type safety
        item.ItemId;   //will throw a compiler exception
    }
    

    Компилятор C # довольно умен - у всех типов, генерируемых отдельно, будет один и тот же сгенерированный тип, если их свойства совпадают.

    Кроме того, если у вас есть intellisense, имеет смысл использовать var везде, где ясен контекст.

    //less typing, this is good
    var myList = new List<UnreasonablyLongClassName>();
    
    //also good - I can't be mistaken on type
    var anotherList = GetAllOfSomeItem();
    
    //but not here - probably best to leave single value types declared
    var decimalNum = 123.456m;
    

    Я полагаю, это зависит от вашей точки зрения. Лично у меня никогда не возникало проблем с пониманием фрагмента кода из-за var " неправильного использования " и моих коллег, и я использую его довольно часто. (Я согласен с тем, что Intellisense является огромным подспорьем в этом отношении.) Я приветствую его как способ устранения повторяющихся ошибок.

    В конце концов, если такие утверждения, как

    var index = 5; // this is supposed to be bad
    
    var firstEligibleObject = FetchSomething(); // oh no what type is it
                                                // i am going to die if i don't know
    

    на самом деле это было невозможно, никто не использовал бы языки с динамической типизацией.

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

    Например, я бы использовал var в этом случае, потому что сразу видно, что x будет иметь тип " MyClass ":

    var x = new MyClass();
    

    Я бы НЕ использовал var в таких случаях, потому что вам нужно навести курсор мыши на код и посмотреть подсказку, чтобы увидеть, какой тип возвращает MyFunction:

    var x = MyClass.MyFunction();
    

    Особенно я никогда не использую var в тех случаях, когда правая часть - это даже не метод, а только значение:

    var x = 5;
    

    (потому что компилятор не может знать, нужен ли мне байт, short, int или что-то еще)

    Для меня антипатия к var показывает, почему билингвизм в .NET важен. Для тех программистов C #, которые также работали на VB .NET, преимущества var очевидны. Стандартное объявление C #:

    List<string> whatever = new List<string>();
    

    это эквивалентно, в VB .NET, набирать это:

    Dim whatever As List(Of String) = New List(Of String)
    

    Никто не делает этого в VB .NET, хотя. Было бы глупо, потому что начиная с первой версии .NET вы смогли это сделать ...

    Dim whatever As New List(Of String)
    

    ... который создает переменную и инициализирует ее в одну достаточно компактную строку. Ах, а что если вам нужен IList < string > , а не List < string > ? Ну, в VB .NET это означает, что вы должны сделать это:

    Dim whatever As IList(Of String) = New List(Of String)
    

    Точно так же, как вы должны делать в C #, и, очевидно, не можете использовать var для:

    IList<string> whatever = new List<string>();
    

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

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

    Те, кто говорит: «Неважно, используйте то, что вам нравится», не видят всей картины. Каждый в тот или иной момент подберет чужой код, и ему придется иметь дело с любыми решениями, которые они приняли во время написания. Достаточно плохо иметь дело с радикально различными соглашениями об именах или - с классическими стилями захвата, без добавления всего « var или нет» в микс. В худшем случае один программист не использовал var , а затем приходит сопровождающий, который любит его и расширяет код, используя его. Так что теперь у вас нечестивый беспорядок.

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

    Я не против динамической типизации, и я не против имплицитной типизации - в языках, которые предназначены для них. Мне очень нравится Python. Но C # был задуман как статически явно типизированный язык, и так оно и должно быть. Нарушение правил для анонимных типов было достаточно плохо; Позволить людям пойти дальше и сломать идиомы языка еще больше - это то, что меня не устраивает. Теперь, когда джинна нет в бутылке, он никогда не вернется. C # будет балканизирован в лагеря. Не хорошо.

    Много раз во время тестирования я обнаруживал, что у меня есть такой код:

    var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
    Console.WriteLine(something);
    

    Теперь, иногда, я хочу посмотреть, что содержит само SomeOtherThing, SomeOtherThing не тот тип, который возвращает CallMethod (). Так как я использую var, я просто изменяю это:

    var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
    

    на это:

    var something = myObject.SomeProperty.SomeOtherThing;
    

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

    Для любителей, которые думают var экономит время, для ввода текста требуется меньше нажатий клавиш:

    StringBuilder sb = new StringBuilder();
    

    чем

    var sb = new StringBuilder();
    

    Пересчитай их, если мне не веришь...

    19 против 21

    Я объясню, если понадобится, но просто попробуй...(в зависимости от текущего состояния вашего intellisense вам, возможно, придется ввести еще пару для каждого из них)

    И это верно для любого типа, о котором вы только можете подумать!!

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

    Я разбил var по всем местам, единственные сомнительные места для меня - это внутренние короткие типы, например Я предпочитаю int i = 3; , чем var i = 3;

    Это, конечно, может упростить ситуацию из кода, который я написал вчера:

    var content  = new Queue<Pair<Regex, Func<string, bool>>>();
    ...
    foreach (var entry in content) { ... }
    

    Это было бы очень многословно без var .

    Приложение. Небольшое время, проведенное с языком с выводом типа real (например, F #), покажет, насколько хороши компиляторы для получения правильного типа выражений. Это определенно означало, что я склонен использовать var столько, сколько я могу, и использование явного типа теперь указывает, что переменная не относится к типу инициализирующего выражения.

    Нет, за исключением того, что вам не нужно писать имя типа дважды. http://msdn.microsoft.com/en-us/library/bb383973. ASPX

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top