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

E>Кстати, хочется спросить, а почему возвращаемые значения все время присваиваются как var, в результате я о типе могу лишь догадываться (компилятор то тип знает, а вот я не знаю)? Имхо очертененно уменьшает читаемость текста. Я один такой, кто б предпочел это ключевое слово не использовать без крайней необходимости?

Не один.

E>Может мне объяснить сакральный смысл использования var везде где только можно?

Сакральный смысл заключается в экономии на спичках. 'string str;' это же целых 11 символов, а 'var str;' всего 8 символов.

Это же круто, что мы на целых 3 символа меньше записали, а читабельность кода... кому она нужна?

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

U>Это же круто, что мы на целых 3 символа меньше записали, а читабельность кода... кому она нужна?

Как-то ты неправдоподно эти три символа посчитал.

OuterNamespace.InnerNamespace.SomeLibraryClass c1 = new OuterNamespace.InnerNamespace.SomeLibraryClass();
var c2 = new OuterNamespace.InnerNamespace.SomeLibraryClass();

Какие преимущества в читабельности у первого варианта перед вторым?

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

VD>>Нет не один. Есть еще много людей которые не могут переступить через свои привычки. Но со временем ваш лагерь будет рядеть. Уж такова природа человеческая. Сначала человек воспринимает все новое в штыки, а потом начинает считать это новое само собой разумеющимся.
E>Это новое старо как мир . В языках с динамической типизацией уже лет 20 считают, что лучше var ничего нет, и не будет.

Как сказать. Все же между динамическими языками и языками с выводом типов есть огромная разница.
В прочем, это скорее аргумент "за", а не "против".

VD>>Если вопрос тебя действительно интересует, то давай начнем с вопросов к тебе.
VD>>1. Попробуй пройтись по статье и найти все места где тип переменных не очевиден?
E>Очевиден то он очевиден, но это напрягаться надо. И нет гарантии что где-то внутри цепочки вызовов тип не поменяется, более того, он меняется (дергается toString).

VD>>2. Задумывался ли ты над тем, что вывод типов есть не только для переменных объявленных с использованием var, но и при вызове методов (особенно обобщенных)? Чем, скажем вот этот код:
VD>>

VD>>PrintSeq(array1.Reverse().Where((name, i) => i % 2 == 0));
VD>>var result = array1.Reverse().Where((name, i) => i % 2 == 0);
VD>>PrintSeq(result);
VD>>

VD>>?
E>Именно из соображений плохой читаемости я в основном предпочитаю второй тип записи (естественно не var, а имя типа). Пишу первым способом только что-то тривиальное, из соображений чтоб места было меньше (например частичный перенос данных из одного объекта в другой type1.setName1(type2.getName2())).

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

А почему нет ответа на первый попро?

VD>>3. Почему поборники типизации переменных спокойно пишут SQL-запросы не указывая типов для возвращаемых колонок и при этом не возмущаются по поводу потери информации?
E>А я кстати возмущаюсь, что для типов возвращаемых колонок не указывается тип, когда приходится пользоваться SQL. Именно по этому предпочитаю вместо его HQL. Но и в HQL не все хорошо, в случае с наследованием сущностей далеко не тривиально узнать кого ж я получил из запроса и могу ли я дернуть соответствующее свойство — мне очень не хватает возможности указания типа даже в HQL запросе.

Я не знаток Гибернейта, но первый же найденный мною пример HQL-запроса показал, что типы колонок в нем так же не указываются:
http://www.java2s.com/Code/Java/Hibernate/SelectSQL.htm

Session session = HibernateUtil.currentSession();
    
String sql = "select {supplier.*} from Supplier supplier";
            
SQLQuery query = session.createSQLQuery(sql);
query.addEntity("supplier", Supplier.class);
List results = query.list();
displaySupplierList(results);

Кто-то из нас пытается выдать желаемое за действительное?

VD>>От себя могу сказать только одно. По программировав с годик на языке программирования поддерживающем вывод типов, начинаешь относиться к аннотации типов значительно спокойнее и возвещение. Со временем приходит понимание, что главное, чтобы код был понятным тебе и окружающим. А всякие мелочи вроде аннотации типов и даже кошерность названий переменных — это все пуританство и борьба с ветряными мельницами.
E>JavaScript и VBScript пойдет?

Нет. Пойдут:
Nemele, Scala, OCaml, Haskel и т.п.

E>2 года опыта достаточно? Я как раз попрограммировав на этих языках наоборот на строгую типизацию намолиться не могу.

А что ты понимаешь под термином "строгая типизация"? У тебя вообе какая-то каша в голове. Строгая типизация может быть как у статически-типизированных языков (все вышеперечисленные), так и у динамически-типизированных (приведенный тобой JavaScript весма строго-тапизирован). Ты видимо путаешь строгую и статическую типизацию. Но по любому JavaScript динамически-типизирован и в никакого опыта программирования на статически-типизированном языке с выводом типа на нем получить нельзя.

E>И относительно того, что при написании все будет хорошо, студия по нажатию точка все возможные варианты скажет. Код в основном читается, а не пишется. Один раз написал, 100 раз потом прочитал.

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

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

E> Типы я обычно помню наизусть, а вот что принимает и что возвращает функция я обычно не помню, особенно если это не ясно из функции.

Вот тебе на! А что же ты тогда споришь? Как раз типы параметров функций почти во всех мэйнстрим языках (разве что в С — нет) выводятся из инициализации. Более того ты даже не знаешь что за функция вызвана, так как ее тип определяется компилятором по весьма сложному алгоритму разрешения перегрузки.

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

Так что ты сам себе противоречишь.

E>В случае если все аргументы var и возвращается туда же, мне придется лезть смотреть что это за функция и что она принимает.

Что за "var"-аргументы? Ты видимо думаешь, что C# 3.0 ведет себя как скрипт? Отнюдь. Типы аргументов четко определены. Просто они не указываются явно (никогда). Если ты твои чаянья были притворены в жизнь, то писать пришлось бы вот такую жудь:

void PrintSeq(System.IEnumerable[int] array1 System.IEnumerable[string] .Reverse() System.IEnumerable[string] .Where((string name, int i) => int i % 2 == 0));

вместо:

PrintSeq(array1.Reverse().Where((name, i) => i % 2 == 0));

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

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

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

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

E>>И если распечатать код чтоб почитать перед сном — без поддержки студии понимать его будет значительно сложнее.
G>А таким кто-то занимается?

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

Чтобы понять кусок кода без var'ов обычно нужно навестись мышкой на переменные уровня класса, т.к. их тип неочевиден. Чтобы понять кусок кода с var'ами нужно навестись мышкой на все переменные, т.к. var делает неочевидным тип всех переменных. Переменных уровня класса в куске кода обычно 2-3, а всего переменных 10-20. Соответственно в коде с var'ами пользоваться подсказками intellicence приходиться в разы чаще, что ухудшает читабельность очень существенно.

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

E>Это я прекрасно знаю. Но ... код визуально выглядит очень похоже на языки с динамической типизацией. И если распечатать код чтоб почитать перед сном — без поддержки студии понимать его будет значительно сложнее.

Ты видимо отстал от жизни лет эдак на 30. Современные объемы кода не распечатать. Распечатать ты сможешь только одну-две функции. А в них типы будут и так очевидны так как вывод типов работает исключительно на уровне метода.

Более того писать надо стараться так, чтобы у людей не возникало желания задуматься над типами переменных. Код должен быть самодокументированным. Если информации не хватает, то можно добавить комментарий или описать тип явно. C# тут немного проигрывает другим функциональным языкам, так как не позволяет указать тип для произвольного выражения. В других же языках тип можно указать где угодно. Скажем вместо того чтобы указывать тип возвращаемый LINQ-запросом так:

IEnumerable<Order> processedOrdrs = orders.Where(...);
foreach (Order order in processedOrdrs)
  ...

в Немерле (к примеру) можно сделать так:

foreach (order : Order in orders.Where(...))
  ...

При этом компилятор укажет на ошибку если в элемент коллекции не будет иметь тип order (при этом не будет производиться никаких приведений типов). Ну, а то что это последовательность становится ясно из использования ее в foreach-е.
Причем нам совершенно по барабану какой реальный тип этой последовательности (массив, List<Order> или IEnumerable<Order> и т.п.). Нам важно, что мы можем перебрать ее элементы.
Вот на этом и строится использование вывода типов в реальных приложений. А проблемы видятся только тем кто сам это не пробовал.

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

G>>А таким кто-то занимается?
E>А как-же? Простейший пример — когда задают вопрос на форуме или пишут статью, копипастят исходники, и те, кто читают, к исходникам доступа не имеют и им труднее понять получается. Когда просят отревьюить код тоже частенько бросают его в аську. А там никакой студии нет встроенной.

Можно ссылку на сообщение из форума где наличие var-ов мешало бы пониманию кода?

И еще один вопрос. А почему ты не протестуешь против перегрузки и вывода типов параметров? Они ведь точно так же скрывают информацию о типах выражений и функций.

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

VD>Я не знаток Гибернейта, но первый же найденный мною пример HQL-запроса показал, что типы колонок в нем так же не указываются:
VD>http://www.java2s.com/Code/Java/Hibernate/SelectSQL.htm
VD>

VD>Session session = HibernateUtil.currentSession();
    
VD>String sql = "select {supplier.*} from Supplier supplier";
            
VD>SQLQuery query = session.createSQLQuery(sql);
VD>query.addEntity("supplier", Supplier.class);
VD>List results = query.list();
VD>displaySupplierList(results);
VD>

VD>Кто-то из нас пытается выдать желаемое за действительное?

Это не HQL. HQL примерно так выглядит:

IList<Supplier> results = session.CreateQuery("from Supplier").List<Supplier>();

Впрочем в HQL с типизацией тоже все грустно. Все проверки в рантайме. Но типы колонок прописаны в маппинге, с этим все нормально.

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

Q>Как-то ты неправдоподно эти три символа посчитал.

Q>

Q>OuterNamespace.InnerNamespace.SomeLibraryClass c1 = new OuterNamespace.InnerNamespace.SomeLibraryClass();
Q>

Q>Какие преимущества в читабельности у первого варианта перед вторым?

Такой вариант по читабельности эквивалентен или даже чуть лучше:

Q>

Q>OuterNamespace.InnerNamespace.SomeLibraryClass c1 = new ();
Q>

Но к сожалению в шарпе так писать нельзя.

Такой чуть хуже:

Q>

Q>var c1 = new OuterNamespace.InnerNamespace.SomeLibraryClass();
Q>

Т.к. в C# 2.0 тип переменных всегда писался слева и можно было всегда смотреть влево, а теперь иногда пишется слева, а иногда справа.

Такой сильно хуже:

Q>

Q>var c1 = GetSomething();
Q>

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

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

U>Чтобы понять кусок кода без var'ов обычно нужно навестись мышкой на переменные уровня класса, т.к. их тип неочевиден. Чтобы понять кусок кода с var'ами нужно навестись мышкой на все переменные, т.к. var делает неочевидным тип всех переменных. Переменных уровня класса в куске кода обычно 2-3, а всего переменных 10-20. Соответственно в коде с var'ами пользоваться подсказками intellicence приходиться в разы чаще, что ухудшает читабельность очень существенно.

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

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

U>Такой сильно хуже:

Q>>var c1 = GetSomething();

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

Да не надо определять глазами этот тип! По той же причине, по которой часто не надо знать конкретный тип переменной и можно работать с обобщённым интерфейсом. Функция GetSomething() возвращает Something — nuff said.

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

E>Кстати, хочется спросить, а почему возвращаемые значения все время присваиваются как var, в результате я о типе могу лишь догадываться (компилятор то тип знает, а вот я не знаю)? Имхо очертененно уменьшает читаемость текста. Я один такой, кто б предпочел это ключевое слово не использовать без крайней необходимости (и если б использовал, то добавлял бы префиксы или постфиксы к имени, что приходится делать в языках с динамической типизацией чтоб не огрести потом проблем)? Может мне объяснить сакральный смысл использования var везде где только можно?

Varification -- Using Implicitly Typed Locals

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

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

E>>>И если распечатать код чтоб почитать перед сном — без поддержки студии понимать его будет значительно сложнее.
G>>А таким кто-то занимается?

U>Что быстрее просто посмотреть на код или навести мышку на переменную, чтобы воспользоваться подсказкой intellicence?

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

U>Чтобы понять кусок кода без var'ов обычно нужно навестись мышкой на переменные уровня класса, т.к. их тип неочевиден.

Переменные уровня класса — это наверное поля. Каким боком к ним вообще var относится?
Их тип конечно может быть не очевиден (если названия плохие). Но он так же будет не очевиден и без вар. \
У тебя тоже спрошу... А тебе не сильно мешает вывод типов в параметрах функций и алгоритм перегрузки?
Скажем, код типа:

f(x);

ровным счетом ничего не говорит ни о "f", ни о "x".

U>Чтобы понять кусок кода с var'ами нужно навестись мышкой на все переменные, т.к. var делает неочевидным тип всех переменных.

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

В общем, "вы его есть пробовали?" (с).

U> Переменных уровня класса в куске кода обычно 2-3, а всего переменных 10-20. Соответственно в коде с var'ами пользоваться подсказками intellicence приходиться в разы чаще, что ухудшает читабельность очень существенно.

Знаешь, я иногда не могу понять код в котором все типы очевидны как дважды два. Только отладка дает полное (и то не всегда) понимание. Ты наверно гений, раз можешь просто из аннотаций типов понять всю семантику кода.
Ну, гений так гений. Остальные люди не так гениальны. Они воспринимают код не как компилятор. Им чтобы понять, что делает код нужно объяснении автора (например, в виде комментариев или общения по аске), им нужно знать что за значение может быть в той или иной переменной. Им нужны рантайм-типы переменных, а не только те, что вывел компилятор или указал программист.
Учитывая тот факт, что код читаешь не только ты, код нужно писать так, чтобы он был максимально понятен. Это подразумевает интуитивность его восприятия. И редко когда этого качества удается добиться явным указанием типов переменных. А вот породить кашу забив все и вся многометровыми аннотациями типов очень легко.

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

VD>А что ты понимаешь под термином "строгая типизация"? У тебя вообе какая-то каша в голове. Строгая типизация может быть как у статически-типизированных языков (все вышеперечисленные), так и у динамически-типизированных (приведенный тобой JavaScript весма строго-тапизирован).

Вот как раз у JavaScript динамическая слабая типизация (потому что выполняются нявные преобразования между типами).

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

Z>В описываемом коде явные проблемы с именованием переменных и/или методов/выражений с помощью которых эти переменные инициализируются. Можно пример кода, для понимания смысла которого важно знание типа какой-либо переменной?

    string GetNumberAbonent(AspidContext context, ObjectPropertyBox propertyBox, PassportBox passport, ResultBox3 resultBox, int objId)
    {
      if (propertyBox == null || passport == null)
        return string.Empty;
      var objectKind = ObjectExtendedProperty.ObjectKind.FindValue(propertyBox, objId);
      var relationName = string.Empty;
      if (objectKind.CompareTo("п п п ") == 0)
        relationName = "п п п  - п п п ";
      else if (objectKind.CompareTo("пёпё") == 0)
        relationName = "п п п  - п п п п п п п  я п п п  я я п я п ";
      else if (resultBox != null)
      {
        var value = new Alias(objectId, "ObjectName").GetValue(resultBox);
        if (value != null)
          return value.ToString();
      }
      var links = Passport2.п п п п п я я п п п я п _п п я п п я я .FindValue(passport, objId);
      var parentLink = links
        .FirstOrDefault(link => link.ObjectRelTypeName.CompareTo(relationName) == 0);
      if (parentLink == null || parentLink.LinkObjectIds.Length == 0)
        return string.Empty;
      var parentId = parentLink.LinkObjectIds[0];
      var parentProperty = AspidDataModelHlp.GetPropertiesByObjects(context, new[] { parentId },
        ObjectExtendedProperty.ObjectName);
      return ObjectExtendedProperty.ObjectName.FindValue(parentProperty, parentId);
    }

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

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

U>Извиняюсь за проблемы с кодировкой русских символов, из почты копировал.

Я тоже извиняюсь, но вот это:

      var links = Passport2.п п п п п я я п п п я п _п п я п п я я .FindValue(passport, objId);

Понять конечно нельзя. Но не потому, что там тип не указан, а потому, что имя функции в кашу превратилось.

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

Q>Да не надо определять глазами этот тип! По той же причине, по которой часто не надо знать конкретный тип переменной и можно работать с обобщённым интерфейсом. Функция GetSomething() возвращает Something — nuff said.

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

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

Z>Это не HQL. HQL примерно так выглядит:
Z>

Z>IList<Supplier> results = session.CreateQuery("from Supplier").List<Supplier>();
Z>

Z>Впрочем в HQL с типизацией тоже все грустно. Все проверки в рантайме. Но типы колонок прописаны в маппинге, с этим все нормально.

Что нормально? Что делать если мне нужно выбрать не объект, а две его колонки?

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

VD>>А что ты понимаешь под термином "строгая типизация"? У тебя вообе какая-то каша в голове. Строгая типизация может быть как у статически-типизированных языков (все вышеперечисленные), так и у динамически-типизированных (приведенный тобой JavaScript весма строго-тапизирован).

N>Вот как раз у JavaScript динамическая слабая типизация (потому что выполняются нявные преобразования между типами).

Это вопрос очень спорный. Вот в С++ слабая статическая типизация даже если забыть о неявном преобразовании типов.

Во многих источниках под строгостью понимается невозможность некорретного преобразования типов. Например, побитовое преобразование int64 в double или int в указатель. А неявные преобразования могут качественно обрабатываться в рантайме.

Я же говорил о другом. Человек явно путает понятия "строгая типизация" и "статическая типизация".

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

U>Т.к. в C# 2.0 тип переменных всегда писался слева и можно было всегда смотреть влево, а теперь иногда пишется слева, а иногда справа.

Чушь полнейшая. Вот тебе код на C# 1.0:
X(new Y());

U>Такой сильно хуже:

Q>>

Q>>var c1 = GetSomething();
Q>>

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

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

VD>Можно ссылку на сообщение из форума где наличие var-ов мешало бы пониманию кода?
var result = ...
Да, я прекрасно, если заострю внимание, пойму о чем речь. Но беглым взглядом уже сложнее читать, чем IEnumerable<string> result. В любом случае result неудачное имя для переменной. Ладно, на деле, я согласен, что если я заменю все свои аннотации типов на var я почти ничего не потеряю, так как у меня имя переменной отражает тип. И если уж будут сторонники var, я в коде не потеряюсь, при условии что переменные будут называться так, чтоб я мог понять что это такое.

VD>И еще один вопрос. А почему ты не протестуешь против перегрузки и вывода типов параметров? Они ведь точно так же скрывают информацию о типах выражений и функций.
Причина проста. Если мне понадобится узнать как именно работает метод, мне в любом случае потребуется лезть в его код, то есть пользоваться ИДЕ. Как именно он работает чаще всего знать не надо, надо чтоб у него было нормальное имя. А вот типы данных, которыми я оперирую, мне более интересны в большинстве случаев (есть допустим переменная number — число. А числа бывают разные, комплексные, целые, беззнаковые, с фиксированной точностью, с неограниченной точностью — и про то, каким числом ты оперируешь очень полезно всегда помнить, так как есть тонкости. Если я тонкости не знаю, я могу про это забыть и допустить ошибку. Вероятность того, что я при беглом просмотре найду ошибку в чужом коде гораздо выше, если я вижу тип).