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

_FR>>>>Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.
L>>>Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.
_FR>>Формулировки не понял, можешь конкретнее написать?

L>string test() {
L>  return "";
L>}

L>void use1() {
L>  var t = test();
L>}

L>void use2() {
L>  string t = test();
L>}

L>Меняем тип возвращаемого значения test на int.
L>use1 — не сломался. use2 — сломался.
L>Итого: когда не использовали var — изменение увидели, что опровергает выделенное выше.

Ты, как будто, не подумал, о чём написал я. Как на счёт такого кода:

    private static IList<int> GetItems() {
      return new List<int>(new[] { 1, 2, 3, 4, 5 });
    }

    private static void Test1() {
      var items = GetItems();
      items.Add(10);
    }

    private static void Test2() {
      IList<int> items = GetItems();
      items.Add(10);
    }

Если GetItems() переписать так:

    private static int[] GetItems() {
      return new[] { 1, 2, 3, 4, 5 };
    }

то уже Test2(), без var, будет компилироваться, но не будет работать, а вот вариант с var даже не скомпилируется, что нам и требуется. А если мы поменяем GetItems() этак:

    private static IList<int> GetItems() {
      return new[] { 1, 2, 3, 4, 5 };
    }

то вне зависимояти от наличия var методы Test1 и Test2 будут компилироваться, но не будут работать. Поэтому я и говорю, что использование по наличию var ничего нельзя сказать о том, надо ли что-то особенно перетестировать: и помимо var есть много условностей от снимаемой тобой метрики.

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

_FR>то вне зависимояти от наличия var методы Test1 и Test2 будут компилироваться, но не будут работать. Поэтому я и говорю, что использование по наличию var ничего нельзя сказать о том, надо ли что-то особенно перетестировать

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

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

_FR>>то вне зависимояти от наличия var методы Test1 и Test2 будут компилироваться, но не будут работать. Поэтому я и говорю, что использование по наличию var ничего нельзя сказать о том, надо ли что-то особенно перетестировать

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

Да, прециндент есть. а какие выводы ты лично из него делаешь? Выскажи пожалуйста своё мнение.

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

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

_FR>Да, прециндент есть. а какие выводы ты лично из него делаешь? Выскажи пожалуйста своё мнение.

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

Здравствуйте, Lloyd, Вы писали:
L>Я не против var-а, я и сам его местами использую. Я против неявного изменения кода. Если код изменился — это должно быть отражено явно.
Это очень странный подход.
Весь опыт индустрии софтостроения — это попытка локализовать изменения. А ты хочешь назад в пещеры?
Ну вот поясни специально для отсталого меня, в чем разница двух изменений:

A: version 1

using(Stream s = OpenMessageStream())
{
  s.Read(...)...;
}

FileStream OpenMessageStream()
{
  return ....
}

A: version 2

using(Stream s = OpenMessageStream())
{
  s.Read(...)...;
}

NetStream OpenMessageStream()
{
  return ....
}

B: version 1

using(var s = OpenMessageStream())
{
  s.Read(...)...;
}

FileStream OpenMessageStream()
{
  return ....
}

B: version 2

using(var s = OpenMessageStream())
{
  s.Read(...)...;
}

NetStream OpenMessageStream()
{
  return ....
}

?
В обоих случаях поменялся фактический тип s. Ну и что? В обоих случаях в месте использования изменение оказалось неявным.

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

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

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

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

_FR>А почему "интерфейс" — это именно некий тип? Это лишь ограничение конкретного компилятора. Интерфейсы служат для уменьшения зависимости между частями кода, в частности, для того, что бы метод, возвращающий некое значение мог начать возвращать другое значение (другого конкретного типа), а код "снаружи" об этом бы не узнал. В таком случае указанная тобой метрика становится бесполезной, ибо код стал работать по другому, а тект-то не поменялся, а перетестирование может потребоваться.

Интерфейс все-таки тип.

_FR>"var" — это ещё один шаг, после абстрактных классов и интерфейсов, позволяющий уменьшить связанность кода. Duck-нотация с самого начала использовалась в c#, и никому не мешала. Применение "var" позволяет шире внедрить её использование, что, повторюсь, ещё более снизит зависимость кусков кода друг от друга.

var связанность кода никак не уменьшает.

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

_FR>…Посмотри сам…

Кстати, пост в тему: When to use Type Inference

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

_FR>>…Посмотри сам…

_FR>Кстати, пост в тему: When to use Type Inference

* It does not reduce type safety. This doesn't allow for any late binding, type unsafe functions or the like. It simply lets the compiler chose the type for you.

Указание типа тоже "does not reduce type safety"

* It will actually increase type safety in your code. The best example of this is the foreach statement on non-generic IEnumerable instances. These foreach statements are all technically unsafe because the compiler must do a cast of the Current member under the hood. This declaration looks no different than the type safe generic version of IEnumerable. Using var will force you to write an explicit cast.

foreach (SomeType cur in col)

foreach ( var cur in col.Cast<SomeType>())

И чем это лучше?

* Maintains the principles of DRY. This is mostly true for cases where you have an explicit constructor on the RHS.

С этим согласен. Если справа есть указание имени типа, то DRY. Если нет, то repeat-а нет, а следовательно аргумент в этом случае не применим и надо указывать тип.

* For some types, this is a requirement in order to use the type (anonymous types for instance). I'm a big fan of consistency and since I must have some instances use type inference, I'd like to use them everywhere.

С этим не поспоришь.

* Makes refactoring easier. I re-factor, a lot. I constantly split up or rename types. Often in such a way that refactoring tools don't fixup all of the problems. With var declarations I don't have to worry because they just properly infer their new type and happily chug along. For explicit type cases I have to manually update all of the type names.

Порождает неконтролируемые изменения. Скорее недостаток, чем достоинство.

* Less typing with no loss of functionality.

Несмешно. Особенно если использовать resharper.

Вывод: приведенные аргументы скорее не в пользу пункта 1 (Whenever it's possible), а за пункт 2 (Only when it's absolutely clear what the type is). Т.е. собственно за то, что я и предлагал.

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

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

_FR>>…Посмотри сам…

_FR>Кстати, пост в тему: When to use Type Inference

В комментах там же интересная ссылка с примерами:

здесь