Злой из 'var' в C#? [дубликат]

I think it should be used in those situations where the type is clearly specified elsewhere in the same statement:

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

is a pain to read. This could be replaced by the following with no loss of clarity:

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

Популярная викторина!

Что это за тип:

var Foo = new string[]{"abc","123","yoda"};

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

var Bar = {"abc","123","yoda"};

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

Ура.

Never say never. I'm pretty sure there are a bunch of questions where people have expounded their views on var, but here's mine once more.

var is a tool; use it where it's appropriate, and don't use it when it's not. You're right that the only required use of var is when addressing anonymous types, in which case you have no type name to use. Personally, I'd say any other use has to be considered in terms of readability and laziness; specifically, when avoiding use of a cumbersome type name.

var i = 5;

(Laziness)

var list = new List<Customer>();

(Convenience)

var customers = GetCustomers();

(Questionable; I'd consider it acceptable if and only if GetCustomers() returns an IEnumerable)

Прочтите о Haskell. Это статически типизированный язык, на котором вам редко нужно указывать тип чего-либо. Таким образом, он использует тот же подход, что и var, в качестве стандартного «идиоматического» стиля кодирования.

Если компилятор может что-то выяснить за вас, зачем писать одно и то же дважды?

Мой коллега сначала был очень против. to var, как и вы, но теперь начал его использовать. Он беспокоился, что это сделает программы менее самодокументированными, но на практике это вызвано в большей степени слишком длинными методами.

var MyCustomers = from c in Customers 
                  where c.City="Madrid" 
                  select new { c.Company, c.Mail };

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

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

РЕДАКТИРОВАТЬ: Чтобы немного расширить это (на случай, если это звучит так, как будто я не поддерживаю var):

В Великобритании (на по крайней мере, в то время, когда я пошел), было стандартной практикой заставлять студентов, изучающих информатику, учиться программировать на стандартном машинном обучении. Как и другие функциональные языки, в нем есть система типов, которая позорит языки в стиле C ++ / Java.

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

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

А вот и вещь с SML: он использует вывод типа исключительно при назначении. Так что я не думаю, что вывод типов может быть плохим по своей сути.

Теперь вот что с SML: он использует вывод типа исключительно при присваивании. Так что я не думаю, что вывод типов может быть плохим по своей сути.

Теперь вот что с SML: он использует вывод типа исключительно при присваивании. Так что я не думаю, что вывод типов может быть плохим по своей сути.

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

Как указал Эрвикер, есть несколько функциональных языков, одним из которых является Haskell, а другим - F #, где такой вывод типов используется гораздо более широко - аналогия C # будет объявлять возвращаемые типы и параметры типы методов как "var", а затем компилятор определит для вас статический тип. Статическая и явная типизация - две ортогональные проблемы.

На самом деле, можно ли вообще сказать, что использование «var» является динамической типизацией? Насколько я понял, для этого и предназначено новое ключевое слово «dynamic» в C # 4.0. "var" предназначен для вывода статического типа. Поправьте меня, если я ошибаюсь.

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

Однако это определенно простой способ сократить строки нового объявления, и я использую его для этого все время.

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

Вторая проблема, с которой я сталкиваюсь, - это когда я не уверен, какой метод использовать (и я просто просматриваю автозаполнение). ЕСЛИ я выберу неправильный и ожидаю, что это будет тип FOO, а это тип BAR, тогда потребуется время, чтобы понять это.

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