Здравствуйте, Коваленко Дмитрий, Вы писали:

S>>С точки зрения читателя такого кода, это очень неудобно.
S>>Это создает лишние трудности для его понимания.
S>>Выглядит это просто так, что человеку лень даже тип указать.
S>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

КД>Коротко говоря — лично мне все это по-барабану

КД>Потому что меня прёт

Слова не мальчика, но мужа

Здравствуйте, sunshine, Вы писали:

S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

Дело привычки. Люди, пишущие на динамических языках вон привыкли и не жалуются. В случае же C# это просто синтаксический сахар (исключая случаи анонимных типов и LINQ), как foreach.

Здравствуйте, Аноним, Вы писали:

А>То "new List<int>();" происходит в конструкторе, путь и статическом, но конструкторе. И получается объявление вида:
А>"private static var sm_Tests;"
А>И действительно не понятно, какой тип должна иметь эта переменная. Конечно, это могли бы и обойти, но видимо не захотели...

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

S>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

У нас правила такие: var использовать только тогда, когда тип переменной очевиден из ее объявления, для исключения дублирования:

OK:

var my = new My();
var my = GetInstance<My>();
var my = obj as My;
var my = (My) obj;

Не OK:

var my = GetInstance();
foreach (var my in _allMy){}

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

Здравствуйте, sunshine, Вы писали:

S>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>Привет всем.

КД>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

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

Здравствуйте, k.o., Вы писали:

KO>Здравствуйте, sunshine, Вы писали:

S>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>Привет всем.

КД>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
Скорее всего эту ветку нужно перенести в священные войны
Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

Здравствуйте, -VaS-, Вы писали:

VS>У нас правила такие: var использовать только тогда, когда тип переменной очевиден из ее объявления, для исключения дублирования:

Есть ещё случаи, когда тип не важен.

protected virtual void OnSomeActionDoing(SomeActionEventArgs eventArgs)
{
    var eventHandler = SomeActionDoing; // Пофиг!

    if (eventHandler != null)
    {
        eventHandler(this, eventArgs); // Этот код не поменяется. Судьба.
    }
}

Здравствуйте, AlexNek, Вы писали:

AN>Здравствуйте, k.o., Вы писали:

KO>>Здравствуйте, sunshine, Вы писали:

S>>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>>Привет всем.

КД>>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
AN>Скорее всего эту ветку нужно перенести в священные войны


AN>Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

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

Здравствуйте, k.o., Вы писали:

KO>Здравствуйте, AlexNek, Вы писали:

AN>>Здравствуйте, k.o., Вы писали:

KO>>>Здравствуйте, sunshine, Вы писали:

S>>>>Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>>>>>Привет всем.

КД>>>>>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.

S>>>>С точки зрения читателя такого кода, это очень неудобно. Это создает лишние трудности для его понимания. Тип ведь частенько хочется узнать, все-таки. Ну хорошо, отказались от венгерской нотации мотивируя это тем, что, мол, "а я наведу мышку на переменную, мне тип и покажется". Использование же var и это утешение отменяет. Выглядит это просто так, что человеку лень даже тип указать. Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>>>>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

KO>>>Выделенное, вообще говоря, наглая ложь. Единственный случай когда это верно, это если тип анонимный, тем не менее, подобное использование var, почему-то считается более оправданным, чем во всех остальных случаях, когда тип можно узнать. Что действительно непонятно, так это логика людей, считающих, что var следует использовать только для анонимных типов, по причине того, что неупоминание типов в коде, якобы, ухудшает читабельность.
AN>>Скорее всего эту ветку нужно перенести в священные войны
KO>

AN>>Но вот лично я просто не переношу код с var. Именно по причине ухудшения читабельности. Ну привык я видеть тип слева.

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

Здравствуйте, sunshine, Вы писали:

S>Мотивация повсеместного использования этого вообще непонятна. Кроме редкий ситуаций, для который его и придумали (создание анонимных типов в Linq-запросах), непонятно совершенно — где его применение еще может быть оправдано.
S>Такое нецелевое использование, на мой взгляд, признак дурного тона в программировании.

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

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

Здравствуйте, SergeyT., Вы писали:

ST>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>

ST>class A
ST>{
ST>  public var field = new {I = 1, S = "2"};
ST>}
ST>

Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

Здравствуйте, adontz, Вы писали:

A>Есть ещё случаи, когда тип не важен.

A>

A>protected virtual void OnSomeActionDoing(SomeActionEventArgs eventArgs)
A>{
A>    var eventHandler = SomeActionDoing; // Пофиг!

A>    if (eventHandler != null)
A>    {
A>        eventHandler(this, eventArgs); // Этот код не поменяется. Судьба.
A>    }
A>}
A>

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

Здравствуйте, antigravity, Вы писали:

A>Дело привычки. Люди, пишущие на динамических языках вон привыкли и не жалуются. В случае же C# это просто синтаксический сахар (исключая случаи анонимных типов и LINQ), как foreach.

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

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, SergeyT., Вы писали:

ST>>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>>

ST>>class A
ST>>{
ST>>  public var field = new {I = 1, S = "2"};
ST>>}
ST>>

А>Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

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

Короче говоря, мне все эти аргументы кажутся надуманными. А то C# начинает напоминать C++, автор которого тоже не следовал принципу "сказал А, говори Б". Там тоже много таких моментов "здесь можно, а тут нельзя", "тут помню, тут не помню". Надо было или не делать вывод типов вовсе, или делать полноценно.

Лично я считаю вывод типов в C# ошибкой.

Здравствуйте, Аноним, Вы писали:

А>А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

А потом они колбасят форум вопросами о том как в .Net сделають структурную типизацию и выясняется что никак и компилятор поддерживает неизвестно что.

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Полюбил я ключевое слово var всей душой и телом. И юзаю его везде где только можно.
Д>И сильно расстроился когда компилятор (VS2010) ниасилил
КД> private static var sm_Tests=new List<int>();
КД>Ну что за ботва!

Всё элементарно — шарпоклепатели а-ля Липперт написали компилятор, неспособный выводить тип полей класса — var работает только в пределах методов. Напрягать зад, чтобы кто-то вместо Dictionary<int, string> написал var — им лениво, возможно даже это потребовало бы переписывания трети компилера. В результате Липперт пишет гнилые отмазки, позорясь на весь тырнет, но делая это с умным видом.
Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ, весь вопрос только в архитектуре компилера. Возможно даже это прогиб под студию, чтобы та побыстрее интеллисенсила — граблесофт и не такое может.

Здравствуйте, Аноним, Вы писали:

ST>>>

ST>>>class A
ST>>>{
ST>>>  public var field = new {I = 1, S = "2"};
ST>>>}
ST>>>

А>Извиняюсь, не в тему ответил. Я написал о проблемах с типизацией, а у вас речь шла о том, что анонимный класс будет закрытым. Ну, делать открытые данные вообще неправильно. Можно и запретить делать такие открытые данные, а можно и разрешить, в чем проблема-то? Ну сгенерирует для него компилятор класс с каким-нибудь нелепым названием, ну и ладно.

То, что открытые поля делять неправильно совсем не означает, что это невозможно. Кроме того, существуют классы, единственная обязанность которых — это хранение данных. И в них, как раз очень часто используется field-like инициализация, что делает эти классы отличным кандидатом на использование этой фичи.

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

А>Короче говоря, мне все эти аргументы кажутся надуманными. А то C# начинает напоминать C++, автор которого тоже не следовал принципу "сказал А, говори Б". Там тоже много таких моментов "здесь можно, а тут нельзя", "тут помню, тут не помню". Надо было или не делать вывод типов вовсе, или делать полноценно.

Мир жесток, несправедлив и, вообще, не идеален.

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

А>Лично я считаю вывод типов в C# ошибкой.

Аргументированное заявление.

Здравствуйте, matumba, Вы писали:

M>Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ.

Вы либо добросовестно заблуждаетесь, либо троллите. Тут уже писали, что .Net разделяет код на сборки и это вносит свои коррективы.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, SergeyT., Вы писали:

ST>>Вопрос следующий: что делать с анонимными классами? Ведь с точки зрения синтаксиса языка следующий код должен был бы быть абсолютно законным:

ST>>

ST>>class A
ST>>{
ST>>  public var field = new {I = 1, S = "2"};
ST>>}
ST>>

А>Да ничего не делать. Почему нельзя запустить типизатор, и если он вернул результат, что нельзя вывести тип, так об этом пользователю и говорить? Почему все разработчики компиляторов все время стараются сделать компилятор таким хитрым, скрытным и "некоммуникабельным", чтобы он сам там чего-то молча выводил в соответствии с каким-то хитромудрым пунктом стандарта X.X.X.X и о проблемах никому не говорил. А потом с умным видом придумывают глупые оправдания невозможности сделать какую-нибудь фичу, которая в других языках есть уже сто лет. И все с пониманием кивают: "Да, мы понимаем, это сложно сделать, да, разработка компиляторов это сложное дело". А потом какие-нибудь ребята из проекта Nemerle, которые вообще в свободное время этим занимаются, берут и за пару часов делают то, невозможность чего какой-нибудь Эрик Липперт пространно разъяснял в своем высокоинтеллектуальном блоге.

В Nemerle так тоже делать нельзя
Одна из причин замедление компиляции.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, matumba, Вы писали:

M>>Поле это или локальная переменная — НИКАКОЙ РАЗНИЦЫ.

A>Вы либо добросовестно заблуждаетесь, либо троллите. Тут уже писали, что .Net разделяет код на сборки и это вносит свои коррективы.

Бросайте это школоло "тролите"! Никому ваши нервы не упёрлись. Возможно, я заблуждаюсь, но в упор не вижу разницы между типизацией поля и локальной переменной. Поясните, причём тут сборки?

По идее, в каком бы виде поле ни записывалось, оно обрабатывается компилером. Только в одном случае нас вынуждают писать "тип имя", а в другом можно "var имя = НекийВычислимыйТип" — компилеру так сложно пройтись по "НекийВычислимыйТип"?