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

K>Здравствуйте, Pavel M., Вы писали:


PM>>Попробуйте
PM>>FileShare.ReadWrite

K> спасибо, получилось!

просто тот процесс поставил ReadWrite, а Вы пытались изменить на Read

PM>>PS А почему Вы везде var используете? Ужас

K> /me краснеет

K> ну это, мейнстрим, решарпер советует и все такое

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

var line = sr.ReadLine();

Читая строчку, приходится домысливать, что за тип)

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

PM>Вы экономите 4 буквы, "string" -> "var", однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются? ReadLine возвращает String — это и ежу понятно, а какой-нибудь CoreParser.GetSemanticalTreeInternal?
PM> Я сомневаюсь, что Ваши программы основываются только на примитивах.

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

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

D> А это ведь гораздо более неочевидно...

Вы экономите 4 буквы, "string" -> "var", однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются? ReadLine возвращает String — это и ежу понятно, а какой-нибудь CoreParser.GetSemanticalTreeInternal? Я сомневаюсь, что Ваши программы основываются только на примитивах.

Когда в язык вводится новая конструкция для упрощений работы с другими технологиями (LINQ), это не значит, что ее нужно использовать везде, где только можно и нельзя. Любыми вещами нужно пользоваться разумно.
И еще против Ваших аргументов: мы пишем не код под среду, а используем среду для кода, а также код друг друга и принтер тут совершенно не при чем.

А почему не использую указание типа в аргументах? Потому что читая метод ее легко проследить. Аргументы из ниоткуда не возникают и вникуда не пропадают Variables declarations + method signature доходчиво все показвают, что и какого типа куда пришло и куда это можно передать. А как раз когда везде стоит var — это упомянутую мною цепочку нарушает. "Неизвестно" ,что мы из метода получили. Ах, да, мышкой подергать нужно)

Здравствуйте, _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). Т.е. собственно за то, что я и предлагал.

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

PM>Но нам приходится в голове держать ту же информацию, что и компилятор держит в памяти.

Зачем? Лично я не пытаюсь дублировать при чтении кода компилятор, да это и невозможно, память у меня не абсолютная. Главное при чтении кода — уловить суть, а не проверить типы, и аннотация типов в этом только мешает.

AVK>>и код автоматом становится корректным даже без средств автоматизации.

PM>А раньше это решали с помощью грамотного проектирования AbstractFabric, Builder, etc =)))

Одно другому не мешает, это во-первых. А во-вторых микродизайн очень сильно зависит от используемого языка.

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

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

Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.

L>Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.

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

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

_FR>Приведи пример кода, в котором из-за замены имени типа переменной на var ты не смог бы разобраться?

Это не совсем про читабельность, но все-таки.

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

Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать.
Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

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


PM>Попробуйте
PM>FileShare.ReadWrite

спасибо, получилось!

PM>PS А почему Вы везде var используете? Ужас

/me краснеет

ну это, мейнстрим, решарпер советует и все такое

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

PM>>читабельность кода снижается, когда одни var везде торчат. Например здесь

var line = sr.ReadLine();

PM>>Читая строчку, приходится домысливать, что за тип)

PM>Товарищ Несогласный, Вы можете оспорить данное утверждение?

Можем. Во-первых, название метода ReadLine() вполне явно говорит о типе. Во-вторых, в нормальных условиях с кодом работают в специальной среде разработки, и в случае затруднений достаточно навести мышку на название переменной, или shortcut соответствующий нажать. Вы же не требуете в вызовах методов явно указывать типы аргументов и возвращаемого значения ? И даже названия аргументов не требуете (привет, Objective C!). А это ведь гораздо более неочевидно...

Единственное с чем можно согласиться: при рассмотрении кода вне Visual Studio некоторые проблемы действительно возможны. И может быть их даже нужно решать. Но делать это надо явно не путём приспособления языка и стиля написания исходного кода "под принтер"

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

PM>Вы экономите 4 буквы, "string" -> "var",

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

PM>однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются?

Да. Бо это совсем другая задача. И её нужно решать в любом случае.

PM>ReadLine возвращает String — это и ежу понятно,

Ну вот видите. А что тогда придирались-то к человеку ? Раз "ежу понятно" ?

PM>а какой-нибудь CoreParser.GetSemanticalTreeInternal?

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

PM>И еще против Ваших аргументов: мы пишем не код под среду, а используем среду для кода, а также код друг друга и принтер тут совершенно не при чем.

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

PM>А почему не использую указание типа в аргументах? Потому что читая метод ее легко проследить.

Неправда. Любое нетривиальное выражение в качестве аргумента, например, тот же вызов функции, и ничего Вы уже не проследите.

*А в то что Вы каждый аргумент каждого вызова функции вычисляете отдельно, и складываете в отдельную же локальную переменную с явно заданным типом, я никогда не поверю

PM>Variables declarations + method signature доходчиво все показвают,

Вот именно. Method signature. Которая, в случае вызовов методов, в нормальных условиях узнаётся через IDE, с помощью мышки/shortcut'а.

PM>А как раз когда везде стоит var — это упомянутую мною цепочку нарушает. "Неизвестно" ,что мы из метода получили. Ах, да, мышкой подергать нужно)

Именно так. Не ползать, в поисках объявлений переменных и методов, по коду FAR'ом, а в нормальной IDE просто мышку навести.

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

КЛ>Однако все известные мне merge tool'ы никакие хинты тебе показывать не будут

Совершенно верно. И именно поэтому, и version control, и diff/merge, и инструментарий а-ля Сode Collaborator, всё это должно быть прямо в IDE, и по-полной программе интегрированно с IntelliSense (в форме ReSharper'а, разумеется )

*Надеюсь, JetBrains нам скоро помогут. А то от Microsoft такого счастья не дождаться, TFS ихний уже видели, свят-свят-свят...

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

D>Здравствуйте, Константин Л., Вы писали:

КЛ>>Однако все известные мне merge tool'ы никакие хинты тебе показывать не будут

D>Совершенно верно. И именно поэтому, и version control, и diff/merge, и инструментарий а-ля Сode Collaborator, всё это должно быть прямо в IDE, и по-полной программе интегрированно с IntelliSense (в форме ReSharper'а, разумеется )

D>*Надеюсь, JetBrains нам скоро помогут. А то от Microsoft такого счастья не дождаться, TFS ихний уже видели, свят-свят-свят...

во во

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

КЛ>>>1. Вынужденное зло — это что-то из серии личной неприязни.

AVK>>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.

КЛ>Какие личности? О чем ты?

Ключевое слово я жирным выделил.

КЛ> Да и нет у меня неприязни к var.

Вот и не надо заниматься демагогией.

AVK>>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.

КЛ>Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь.

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

1. Получаем объект автоматизации студии DTE.
   
2. Сканируем все активные проекты в открытом солюшене и выбираем те из них, которые являются проектами C#.
   
3. Находим среди них тот, output assembly которого совпадает с именем сборки.
   
4. Рекурсивно обходим все элементы проекта и находим среди них те, расширение файлов которых соответствует заданному.
   
5. Находим элемент проекта, соответствующий codebehind.
   
6. Находим имя первого типа в файле codebehind (стандартное поведение дизайнеров студии).
   
7. Сравниваем его с заданным.
   
8. Если совпало — возвращаемся к айтему-владельцу и открываем его в редакторе.

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

КЛ>попозже

Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.

КЛ>восприятие кода и экспертная оценка — разные вещи.

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

КЛ> Вот попытка собсвенное восприятие подогнать под экспертную оценку

Аргументы, на основании которых ты заключил, что это так.

КЛ>, да еще и восприятие других людей под нее подогнать — демагогия.

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

AVK>>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.

КЛ>аналогично

Ну и к чему тогда тут обсуждение личностей?

AVK>>С моей стороны никакой демагогии пока нет.

КЛ>ну я другого мнения и не ожидал

По делу есть что сказать?

AVK>>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?

КЛ>и тебе можно, и мне можно. дело только в категоричности высказываний.

Категоричность высказываний — не повод называть эти высказывания демагогией.

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>Допустим, тогда ты должен доказать, что это не личная неприязнь, а общеизвестный факт

AVK>Это ты должен доказывать. Ты же меня в личной неприязни обвинил.

Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?

здесь

Автор: Константин Л.
Дата: 19.10.08

КЛ>>Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска

AVK>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.

по делу ты ничего не ответил, выделю специально жирным чуть ниже

AVK>>>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.

КЛ>>здесь

Автор: Константин Л.
Дата: 20.06.07

. Обрати внимание на закомментированные строки с явной аннотацией типов.

КЛ>>1. Поддержка студии была тогда почти никакой.
КЛ>>2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
КЛ>>3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие

КЛ>>Вот, например, тебе файлик. Разберешься сходу с foreach?

AVK>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?

конечно конечно

macro @foreach (inexpr, body)
  syntax ("foreach", "(", inexpr, ")", body)
  {
    match (ListComprehensionHelper.ExpandRange (inexpr, body)) {
      | Some (expr) => Nemerle.Imperative.Return (expr)
      | None => {}
    }

    def (iter, collection) =
      match (inexpr) {
        | <[ $i in $c ]> => (i, c)
        | e =>
          Message.FatalError ($ "the syntax is 'foreach (x in collection)', "
                                "got $e");
      }
      
    def typer = Macros.ImplicitCTX ();
    def tcollection = typer.TypeExpr (collection);

    // build the body of loop (may contain additional matching)
    def build_definition (val) {
      match (body) {
        | <[ match ($(null)) { ..$cases } ]> =>
          match (iter) {
            | <[ $(x : name) ]> when char.IsLower (x.Id[0]) | <[ (..$_) ]> => ()
            | _ => Message.FatalError ("only simple names available in pattern"
                                       " of foreach with direct matching")
          }

          <[ def $iter = $val; 
             match ($iter) { ..$cases } 
          ]>

        | _ =>
          def mat =
            match (iter) {
              | <[ $pat :> $ty ]> =>
                <[ match ($val :> $ty) { | $pat => $body; () | _ => () } ]>
              | _ =>
                <[ match ($val) { | $iter => $body; () | _ => () } ]>  
            }
          mat.cases.Iter (fun (x : PT.MatchCase) { x.disable_warnings = true });
          mat
      }
    }

    // here we choose if we want to use enumerator pattern
    // of access GetEnumerator through IEnumarable
    // http://www.jaggersoft.com/csharp_standard/15.8.4.htm
    def decide_enumerator_pattern (tyinfo) {
      def all = tyinfo.LookupMember ("GetEnumerator");
      
      def choosen = List.Exists (all, fun (mem : IMember) {
        | meth is IMethod when !meth.IsStatic && meth.GetParameters ().IsEmpty =>
          match (meth.ReturnType.Fix ()) {
            // FIXME: do additional conservative checks              
            | MType.Class (tc, _) when
              !tc.LookupMember ("MoveNext").IsEmpty &&
              !tc.LookupMember ("Current").IsEmpty => true
              
            | _ => false
          }
        | _ => false
      });
      if (choosen)
        <[ $(tcollection : typed).GetEnumerator () ]>
      else
        <[ ($(tcollection : typed) : System.Collections.IEnumerable).GetEnumerator () ]>
    }

    typer.DelayMacro (fun (fail_loudly) {
      match (tcollection.Type.Hint) {
        | Some (MType.Class (tc, args)) =>
          if (tc.InternalType.Nemerle_list_tc != null 
              && tc.SuperType (tc.InternalType.Nemerle_list_tc).IsSome)
          {
            def arg = List.Head (args);
            def definition = build_definition (<[ x ]>);
            Some (<[
              // we explicitly set parameter type to list, because collection's type
              // can be more specific (list.Cons, etc.)
              ($("_N_break" : global) : {
                def foreach_loop (_ : list [$(arg : typed)]) {
                  | x :: xs =>
                    $("_N_continue" : global) : {
                      $definition;
                    }
                    foreach_loop (xs)
                  | _ => ()
                }
                foreach_loop ($(tcollection : typed))
              })
            ]>)
          }
          else {
            def init_body = decide_enumerator_pattern (tc);

            def is_disposable = 
              typer.JustTry (fun () {
                def expr = typer.TypeExpr (init_body);
                expr.Type.Require (<[ ttype: System.IDisposable ]>)
              });

            def finally_body = 
              if (is_disposable)
                <[ (enumerator : System.IDisposable).Dispose () ]>
              else
                <[
                  match (enumerator) {
                    | x is System.IDisposable => x.Dispose ();
                    | _ => ()
                  }
                ]>;

            def definition = build_definition (<[ enumerator.Current ]>);

            Some (<[ 
              def enumerator = $init_body;
              $("_N_break" : global) : {
                def loop () {
                  when (enumerator.MoveNext ()) {
                    $("_N_continue" : global) : {
                      $definition;
                    }
                    loop ();
                  }
                }
                try { loop () } 
                finally { $finally_body }
              }
            ]>)
          }

        | Some (MType.Array (_ , rank)) =>
          def indices  = array (rank);
          def lengths = array (rank);
          for (mutable i = 0; i < rank; ++i) {
            indices [i] = Macros.NewSymbol ();
            lengths [i] = Macros.NewSymbol ();
          }
          def indices_list = List.RevMap (List.FromArray (indices), fun (x) {
              <[ $(x : name) ]> 
          });
          def build_loops (depth)  {
            /// build expression defining iteration symbols
            | 0 => build_definition (<[ cached_collection [..$indices_list] ]>)
            | n => 
              def idx = indices [n - 1];
              <[ for (mutable $(idx : name) = 0; 
                      $(idx : name) < $(lengths [n - 1] : name);
                      ++ $(idx : name)) 
                   $(build_loops (n - 1)) 
              ]>
          }
          mutable sequence = [ <[ $(build_loops (rank)) ]> ];
          if (rank == 1) 
            sequence = <[ def $(lengths [0] : name) = cached_collection.Length ]> :: sequence;
          else
            for (mutable i = rank - 1; i >= 0; --i)
              sequence = <[ def $(lengths [(rank - 1) - i] : name) = cached_collection.GetLength ($(i : int)) ]>
                         :: sequence;

          sequence = <[ def cached_collection = $(tcollection : typed) ]> :: sequence;
          Some (<[ { .. $sequence } ]>)

        | t =>
          when (fail_loudly) {
            def guess =
              match (t) {
                | Some (t) => $ "current best guess about the type is $t"
                | None => "the compiler has no idea what the type might be"
              }
            Message.Error ($ "collection in foreach must be an array or "
                             "type implementing enumerator pattern, $guess");
            Message.Hint ("try specifing the type directly using 'expr : SomeType'");
          }
          None ()
      }
    })
  }

КЛ>>

КЛ>>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.

КЛ>>Не слишком ли загнул, м?

AVK>Фигурная резьба по цитатам? Смайлик ты зачем отрезал? Это во-первых. А во-вторых это совсем не из того сообщения цитата, где ты демагогией обозвал. Из этого делаю вывод — аргументов у тебя нет, одни домыслы. Что и следовало ожидать.

Ок. В конце смайлик. Что это меняет, объясни?

А вот и то, на что я сказал "демагогия":

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

AVK>>>Аргументы, на основании которых ты заключил, что это так.

КЛ>>выше

AVK>Нету выше аргументов. Опять бездоказательный наезд.

Твоя же цитата уже не твоя?

AVK>>>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.

КЛ>>получается как умею.

AVK>Лучше тогда не стоит.

спасибо, но еще попробую

КЛ>> Однако ты свою правду объявил общей. Вот где подгон.

AVK>И опять бездоказательный наезд.

Ну как же

Правда состоит в том[/b], что при чтении, а не написании, кода, знать точное имя типа просто не нужно.

AVK>>>Ну и к чему тогда тут обсуждение личностей?

КЛ>>нету тут обсуждения личностей.

AVK>А это просто вранье.

Не нервничай

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

КЛ>Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?

Что тор, что я считаю экспертной оценкой на самом деле личная неприязнь.

AVK>>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.

КЛ>по делу ты ничего не ответил

Ах вон оно как.

AVK>>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?

КЛ>конечно конечно

Ха ха ха. Вобщем понятно, за душой у тебя ничего нет, флеймишь впустую. На сем и закончим.

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

L>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.

Все равно не очень понятно. var имеет отношение только к изменению контрактов, а контракты у нас проверяет компилятор, так что ничего перетестировать не надо. Если же поменялось внутреннее поведение метода, то оно и без 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. Ну и что? В обоих случаях в месте использования изменение оказалось неявным.

hi!

Коллеги, подскажите.

Пишу код, читающий файлы в каталоге. Один из этих файлов — всегда открыт на запись другой программой(это логи).
Вылетает, соответсвенно, исключение при использовании File.ReadAllLines.
Но при этом тот же FAR или любой просмоторщик его открывает на чтение.

Мне нужно его просто ПРОЧИТАТЬ. Пытаюсь поколдовать перед работой с файлами с

            FileIOPermission permission = new FileIOPermission(FileIOPermissionAccess.Read, pathToData);
            permission.Assert();

и не выходит каменный цветок, все равно имею исключение. Соответственно, другие файлы уже обработать не могу.

Как тут правильно указать параметры доступа и файл прочесть?

            FileIOPermission permission = new FileIOPermission(FileIOPermissionAccess.Read, pathToData);
            permission.Assert();
            try
            {
                foreach (FileInfo f in logs)
                {
                    string[] FileContent = File.ReadAllLines(f.ToString());
                    foreach (string s in FileContent)
                    {
                        if (Regex.IsMatch(s, regesp))
                        {
                            Result.AppendLine(s);
                        }
                    }
                }
            }

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

K>hi!

K> Коллеги, подскажите.

K> Пишу код, читающий файлы в каталоге. Один из этих файлов — всегда открыт на запись другой программой(это логи).
K> Вылетает, соответсвенно, исключение при использовании File.ReadAllLines.
K> Но при этом тот же FAR или любой просмоторщик его открывает на чтение.

K> Мне нужно его просто ПРОЧИТАТЬ. Пытаюсь поколдовать перед работой с файлами с


K>

K>            FileIOPermission permission = new FileIOPermission(FileIOPermissionAccess.Read, pathToData);
K>            permission.Assert();

K>

FileIOPermission здесь не причем. Используй File.Open (String, FileMode, FileAccess) и указывай явно соответствующий режим FileAccess

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

S>FileIOPermission здесь не причем. Используй File.Open (String, FileMode, FileAccess) и указывай явно соответствующий режим FileAccess

попробовал так, не помогло. Все равно кидает исключение, что файл открыт другим процессом

            try
            {
                foreach (FileInfo f in logs)
                {
                    using (var fs = new FileStream(f.FullName, FileMode.Open, FileAccess.Read, FileShare.Read))
                    using (var sr = new StreamReader(fs))
                    {
                        var line = sr.ReadLine();
                        while (line != null)
                        {
                            if (Regex.IsMatch(line, regesp))
                            {
                                Result.AppendLine(line);
                            }
                            line = sr.ReadLine();
                        }
                    }
                }
            }
            catch (IOException e1)

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

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

S>>FileIOPermission здесь не причем. Используй File.Open (String, FileMode, FileAccess) и указывай явно соответствующий режим FileAccess

K> попробовал так, не помогло. Все равно кидает исключение, что файл открыт другим процессом


K>

K>            try
K>            {
K>                foreach (FileInfo f in logs)
K>                {
K>                    using (var fs = new FileStream(f.FullName, FileMode.Open, FileAccess.Read, FileShare.Read))
K>                    using (var sr = new StreamReader(fs))
K>                    {
K>                        var line = sr.ReadLine();
K>                        while (line != null)
K>                        {
K>                            if (Regex.IsMatch(line, regesp))
K>                            {
K>                                Result.AppendLine(line);
K>                            }
K>                            line = sr.ReadLine();
K>                        }
K>                    }
K>                }
K>            }
K>            catch (IOException e1)
K>

Попробуйте
FileShare.ReadWrite

PS А почему Вы везде var используете? Ужас

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



K>> ну это, мейнстрим, решарпер советует и все такое

PM>читабельность кода снижается, когда одни var везде торчат. Например здесь

var line = sr.ReadLine();

PM>Читая строчку, приходится домысливать, что за тип)

Товарищ Несогласный, Вы можете оспорить данное утверждение?

/*var*/ string line = sr.ReadLine(); //так хуже?

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

D>Здравствуйте, Pavel M., Вы писали:

PM>>Вы экономите 4 буквы, "string" -> "var",

D>Лично я, в данном примере, экономлю время на отсутствии необходимости точного выяснения "а что же там возвращает метод XXX() ?"

Без знания "чего же там", Вы не сможете с этим работать по назначению

D>Существенная экономия и на наборе имеет место быть в других случаях, например, при возвращении значений навороченных generic-типов.

Ммм, IntelliSense достаточно хорошо справляется с генериками. И тут-то как раз полезно видеть ,что и куда.

D>Ну вот видите. А что тогда придирались-то к человеку ? Раз "ежу понятно" ?

Я не придрался, я не имею претензий, просто неприятно, когда шарп напоминает JavaScript.

D>Тоже примерно вполне себе понятно. Для действительно же тяжёлых случаев, как я уже говорил, предназначена IDE.

Для действительно тяжелых случаев предназначена документация. А визуальный образ позволяет избежать "примерно вполне себе понятно")))

D>Вы — может быть. А вот я пишу код с учётом возможностей IDE. Бо у меня всегда достаточно маленьких радостей, на которые можно потратить получаемый в итоге выигрыш по времени.

var вместо string и подобные радости сэкономят ровно столько времени, сколько использование StringBuilder в однократном сложении строк прибавит производительности Вашей программе. И Вы не учитываете времени на необходимость распознавания и вспоминаний, когда везде стоит var, var, var, var.... Так можно ресурс мышки истратить за месяц )

D>Неправда. Любое нетривиальное выражение в качестве аргумента, например, тот же вызов функции, и ничего Вы уже не проследите.

D>*А в то что Вы каждый аргумент каждого вызова функции вычисляете отдельно, и складываете в отдельную же локальную переменную с явно заданным типом, я никогда не поверю

Но я знаю, что на входе цепочки методов у меня хотя бы "SematicTreeInternal", а не "var" И я это вижу именно тогда, когда смотрю на эту цепочку методов, мне не приходится дергать мышкой, потом забывать, что там всплыло, потом еще раз дергать =)

D>Вот именно. Method signature. Которая, в случае вызовов методов, в нормальных условиях узнаётся через IDE, с помощью мышки/shortcut'а.

Я имел в виду сигнатуру, которую Вы видете перед глазами, когда пишете тело метода.

PM>>А как раз когда везде стоит var — это упомянутую мною цепочку нарушает. "Неизвестно" ,что мы из метода получили. Ах, да, мышкой подергать нужно)

D>Именно так. Не ползать, в поисках объявлений переменных и методов, по коду FAR'ом, а в нормальной IDE просто мышку навести.

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

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

[]

Однако все известные мне merge tool'ы никакие хинты тебе показывать не будут

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>>Вы экономите 4 буквы, "string" -> "var", однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются? ReadLine возвращает String — это и ежу понятно, а какой-нибудь CoreParser.GetSemanticalTreeInternal?
PM>> Я сомневаюсь, что Ваши программы основываются только на примитивах.

AVK>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.

Смотря какого, и смотря для чего. Основная проблема — merge tools.

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

PM>>>Вы экономите 4 буквы, "string" -> "var", однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются? ReadLine возвращает String — это и ежу понятно, а какой-нибудь CoreParser.GetSemanticalTreeInternal?
PM>>> Я сомневаюсь, что Ваши программы основываются только на примитивах.
AVK>>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
КЛ>Смотря какого, и смотря для чего. Основная проблема — merge tools.

Ты о том, в что в "merge tools" нет интеллисенса и никто не подскажет истинный тип? Не в нём дело. Даже без интеллисенс и чтение и написание с var удобнее.
Или я не уловил суть?

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

_FR>Здравствуйте, Константин Л., Вы писали:

PM>>>>Вы экономите 4 буквы, "string" -> "var", однако предлагаете дергать мышкой над методами чтобы увидеть какие типы где возвращаются? ReadLine возвращает String — это и ежу понятно, а какой-нибудь CoreParser.GetSemanticalTreeInternal?
PM>>>> Я сомневаюсь, что Ваши программы основываются только на примитивах.
AVK>>>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
КЛ>>Смотря какого, и смотря для чего. Основная проблема — merge tools.

_FR>Ты о том, в что в "merge tools" нет интеллисенса и никто не подскажет истинный тип? Не в нём дело. Даже без интеллисенс и чтение и написание с var удобнее.

написание — безусловно, чтение — не всегда, особенно когда isence нет

_FR>Или я не уловил суть?

уловил

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

КЛ>Смотря какого, и смотря для чего. Основная проблема — merge tools.

И что с ними не так?

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>> Я сомневаюсь, что Ваши программы основываются только на примитивах.

AVK>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.

Почему же? Допустим, Вам дали код на поддержку чужой или Вы недавно пришли на проект. В море var'ов можно легко утонуть или затереть мышку до дыр Мало того, что и так незнакомые типы данных, так еще и надо хинтить и запоминать что там всплывало и где.

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

_FR>>Ты о том, в что в "merge tools" нет интеллисенса и никто не подскажет истинный тип? Не в нём дело. Даже без интеллисенс и чтение и написание с var удобнее.

КЛ>написание — безусловно, чтение — не всегда, особенно когда isence нет

Ну вот просто поверь: это вопрос исключительно наличия опыта. Посмотри сам: люди с заслуживающим уважения бэкграундом пропагандируют "var"; создатели языка пропагандируют "var"; даже, надеюсь, в следующей версии мостодонта С++ появится "auto". А кто спорит? Какие их аргументы? Все сводятся к тому, что "неудобно читать".

Диагноз один: не пробовали научиться. Не пробовали. Пока человек не начнёт говорить на неизвестном емё языке, никогда не научится. Пока не начнёт сам использовать какое-то знание, не разберётся в нём. Пока не заставит себя на два-три месяца использовать "var" везде, где только позволяет компилятор, не отвыкнет от мысли, что "надо знать тип переменной".

Не надо! Базовых знаний стандартной библиотеки и Design Guidelines позволят сделать нужные предположения, где это необходимо. Брось писать, притвыкни смотреть на собственоручно написанный код с "var". Потом учись читать чужой. И всё пройдёт.
Единственно, что мешает — "кривые", ни о чём не говорящие имена переменных, но и это со временем проходит: учишся находить баланс между краткостью и достаточностью.

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>Смотря какого, и смотря для чего. Основная проблема — merge tools.

AVK>И что с ними не так?

в низ нет isence

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

_FR>Единственно, что мешает — "кривые", ни о чём не говорящие … одно-двух — буквенные … имена переменных…

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

_FR>Здравствуйте, Константин Л., Вы писали:

_FR>>>Ты о том, в что в "merge tools" нет интеллисенса и никто не подскажет истинный тип? Не в нём дело. Даже без интеллисенс и чтение и написание с var удобнее.

КЛ>>написание — безусловно, чтение — не всегда, особенно когда isence нет

_FR>Ну вот просто поверь: это вопрос исключительно наличия опыта. Посмотри сам: люди с заслуживающим уважения бэкграундом пропагандируют "var"; создатели языка пропагандируют "var"; даже, надеюсь, в следующей версии мостодонта С++ появится "auto". А кто спорит? Какие их аргументы? Все сводятся к тому, что "неудобно читать".

Прости, не поверю. В c# его в основном ввели для линка, в с++ не для читабельности, а для нормального foreach, работы с итераторами и для

template <class T, class U>
auto add(T t, U u)
{
     return t + u;
}

без auto ты просто такой код написать не сможешь

_FR>Диагноз один: не пробовали научиться. Не пробовали. Пока человек не начнёт говорить на неизвестном емё языке, никогда не научится. Пока не начнёт сам использовать какое-то знание, не разберётся в нём. Пока не заставит себя на два-три месяца использовать "var" везде, где только позволяет компилятор, не отвыкнет от мысли, что "надо знать тип переменной".

давай без диагнозов. я использую var. но считаю, кто крайности вроде "var низзя" и "var везде" не для меня. кстати, использую var пару месяцев плотно. до этого некоторое время игрался с nemerle.

_FR>Не надо! Базовых знаний стандартной библиотеки и Design Guidelines позволят сделать нужные предположения, где это необходимо. Брось писать, притвыкни смотреть на собственоручно написанный код с "var". Потом учись читать чужой. И всё пройдёт.

что пройдет? необходимость мержить код с var?

_FR>Единственно, что мешает — "кривые", ни о чём не говорящие имена переменных, но и это со временем проходит: учишся находить баланс между краткостью и достаточностью.

не, нужно искать баланс в использовании var и конкретных типов.

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

_FR>Здравствуйте, Константин Л., Вы писали:


_FR>Ну вот просто поверь: это вопрос исключительно наличия опыта. Посмотри сам: люди с заслуживающим уважения бэкграундом пропагандируют "var"; создатели языка пропагандируют "var"; даже, надеюсь, в следующей версии мостодонта С++ появится "auto". А кто спорит? Какие их аргументы? Все сводятся к тому, что "неудобно читать".

Вы меня улыбнули, честное слово. Я бы не стал тут распинаться, если бы с этим не сталкивался. Помимо шарпа, я кодил и на PHP, и на Perl например, даже на JS немного чтобы вдоволь напользоваться varоподобием. Я не пойму, какую реальную выгоду мы получаем используя var? Даже в той же строчке про ReadLine. Мнение других людей мне интересно, но когда оно позволяет что-то упростить или облегчить жизнь, решить какую-то проблему, тут же я вижу только использование "потому что это есть" и "потому что это модно". Напишите ответ только на этот вопрос и я с Вами соглашусь и здорово начну втыкать везде var и пропагандировтаь его использование.

_FR>Не надо! Базовых знаний стандартной библиотеки и Design Guidelines позволят сделать нужные предположения, где это необходимо.

Есть же application-specific вещи, дизайн на них только наталкивает, подсказывает, но не может указать явно.

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

PM>Без знания "чего же там", Вы не сможете с этим работать по назначению
Запросто. Бо дальше я просто нажимаю Ctrl+Space в соответствующем месте и телемаркет

D>>Существенная экономия и на наборе имеет место быть в других случаях, например, при возвращении значений навороченных generic-типов.
PM>Ммм, IntelliSense достаточно хорошо справляется с генериками.

Проблема в том, что с ними плохо справляюсь я. Выписывать каждый раз какой-нибудь KeyValuePair<CompositeKey<SpreadString, int, HashBase<double>, CompositeKey<string, long>>, Dictionary<...

*Дальше сами продолжайте, раз у Вас IntelliSense такой хороший...

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

PM>И тут-то как раз полезно видеть ,что и куда.

Да не видно тут ничего, в дебрях скобок угловых. Видно же будет, когда на объявленной через var переменной Ctrl+Space нажмёшь.

D>>Ну вот видите. А что тогда придирались-то к человеку ? Раз "ежу понятно" ?
PM>Я не придрался, я не имею претензий, просто неприятно, когда шарп напоминает JavaScript.

Странные у Вас какие-то ассоциации. Неужели ветеран PHP'шник ? Если так, то "гы" много раз

var в C# не имеет ничего общего с JavaScript'ом. Строгая типизация как была, так и осталась. Это всего лишь удобное сокращение. Разве что ключевое слово выбрано не очень хорошо. Тут уже предлагали infer, было бы лучше, на мой взгляд...

PM>Для действительно тяжелых случаев предназначена документация.

Которую нормальные люди смотрят опять-таки с помощью IDE.

PM>А визуальный образ позволяет избежать "примерно вполне себе понятно")))

А этого позволяет избежать IntelliSense.

PM>var вместо string и подобные радости сэкономят ровно столько времени, сколько использование StringBuilder в однократном сложении строк прибавит производительности Вашей программе.

Это если Вы всё только на примитивах пишите. Хм... Где-то я это уже слышал...

PM>И Вы не учитываете времени на необходимость распознавания и вспоминаний, когда везде стоит var, var, var, var.... Так можно ресурс мышки истратить за месяц )

Не смешите. Основное время при "воспоминаниях" уходит на восстановление архитектуры и взаимосвязей. И var'ы тут на последнем месте...

D>>Неправда. Любое нетривиальное выражение в качестве аргумента, например, тот же вызов функции, и ничего Вы уже не проследите.
D>>*А в то что Вы каждый аргумент каждого вызова функции вычисляете отдельно, и складываете в отдельную же локальную переменную с явно заданным типом, я никогда не поверю
PM>Но я знаю, что на входе цепочки методов у меня хотя бы "SematicTreeInternal", а не "var"

А чем Вам это поможет-то ??? Типы аргументов в вызове функции никакой связи с Вашим "входом" не имеют.

PM>Я имел в виду сигнатуру, которую Вы видете перед глазами, когда пишете тело метода.

А она тут чем Вам поможет ???

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

Ну здрасьте, приехали. Если небольшие методы, то значит они вызывают кучу других небольших методов. И как Вы всё эту толпу собрались размещать "перед глазами" ???

PM>А мышкой можно подергать, если из поля зрения попал аргумент. Вобще, я работаю на клавиатуре больше, как программист ,
Вы, наверное, всё-таки хотели сказать "как формокодер"

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

Когда же всё-таки приходится колбасить, то подход разный в зависимости от задач. И если бы Вы внимательно читали мои постинги, то заметили, что на оные действия я ссылаюсь как "с помощью мышки/shortcut'а".

"Чистая" клавиатура более удобна при построении кода, а мышка+клавиатура — при анализе.

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

D>Здравствуйте, Pavel M., Вы писали:

Почитайте другие посты. Оптимально — использовать не чрезмерно, а в меру. Я не ветеран PHPшник, просто не люблю ограничиваться знаниями в одной области и формокодер в последнюю очередь. И, вобще, надоело спорить, ставьте везде var и будет Вам счастье, потом легко на JS перейдете, если потребуется =)) А я буду var ставить где оно упростит жизнь, а не потому что это "модно"

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

AVK>>И что с ними не так?

КЛ>в низ нет isence

А я разве где то что то про isence писал?

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

PM>Почему же?

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

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

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

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

AVK>Здравствуйте, Константин Л., Вы писали:

AVK>>>И что с ними не так?

КЛ>>в низ нет isence

AVK>А я разве где то что то про isence писал?

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

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>>Почему же?

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

Но нам приходится в голове держать ту же информацию, что и компилятор держит в памяти. Что и где было.

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

AVK>и код автоматом становится корректным даже без средств автоматизации.

А раньше это решали с помощью грамотного проектирования AbstractFabric, Builder, etc =)))

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

PM>Имеется в виду,что при merge могут быть проблемы из-за сложной читабельности кода, потому что мышкой не подергать над объявлениями.

Такое ощущение — пишу в пустоту. Читаемость кода с использованием var выше.

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>>Имеется в виду,что при merge могут быть проблемы из-за сложной читабельности кода, потому что мышкой не подергать над объявлениями.

AVK>Такое ощущение — пишу в пустоту. Читаемость кода с использованием var выше.

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

AVK>Здравствуйте, Pavel M., Вы писали:

PM>>Почему же?

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

демагогия

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

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

так читать проще или рефакторить проще?

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

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

КЛ>демагогия

Обоснуй.

КЛ>так читать проще или рефакторить проще?

Оба

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

AVK>Здравствуйте, Константин Л., Вы писали:

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

КЛ>>демагогия

AVK>Обоснуй.

1. Вынужденное зло — это что-то из серии личной неприязни.
2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче? Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".

А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей (впрочем, и я, наверное, тоже). У тебя восприятие такое, у меня такое. Мы можем лишь обменяться мнением, а переубедить др др мы не сможем. Поэтому вся наша дискуссия — сплошная демагогия.

КЛ>>так читать проще или рефакторить проще?

AVK>Оба

Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?

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

КЛ>>>демагогия
AVK>>Обоснуй.
КЛ>1. Вынужденное зло — это что-то из серии личной неприязни.
КЛ>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче? Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".

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

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

КЛ>1. Вынужденное зло — это что-то из серии личной неприязни.

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

КЛ>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче?

С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.

КЛ> Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".

Ну давай. Жду твоих примеров.

КЛ>А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей

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

КЛ> Мы можем лишь обменяться мнением, а переубедить др др мы не сможем.

А я и не собираюсь переубеждать того, кто переубеждаться не хочет.

КЛ> Поэтому вся наша дискуссия — сплошная демагогия.

С моей стороны никакой демагогии пока нет.

AVK>>Оба

КЛ>Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?

А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>1. Вынужденное зло — это что-то из серии личной неприязни.

AVK>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.

Какие личности? О чем ты? Да и нет у меня неприязни к var. Почитай еще раз, что я к нему "испытываю".

КЛ>>2. "...от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.". С каких это пор у нас типы не относятся к решаемой задаче?

AVK>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.

Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь. Но только при чем тут он?

КЛ>> Только давай не будем про обобщенные алгоритмы, а про что нить из прикладной области? Ну то-есть я тебе сам приведу кучу примеров, где типы можно опустить, но это из разряда "Все крокодилы умеют летать, некоторые великаны — крокодилы. Все великаны умеют летать".

AVK>Ну давай. Жду твоих примеров.

попозже

КЛ>>А демагогия это потому, что ты свой личный опыт пытаешься экстраполировать на всех людей

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

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

КЛ>> Мы можем лишь обменяться мнением, а переубедить др др мы не сможем.

AVK>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.

аналогично

КЛ>> Поэтому вся наша дискуссия — сплошная демагогия.

AVK>С моей стороны никакой демагогии пока нет.

ну я другого мнения и не ожидал

AVK>>>Оба

КЛ>>Ну вот тебе читать проще (в 100% случаев), а мне проще, но не всегда. Кто тут прав?

AVK>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?

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

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>>>1. Вынужденное зло — это что-то из серии личной неприязни.

AVK>>>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.

КЛ>>Какие личности? О чем ты?

AVK>Ключевое слово я жирным выделил.

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

КЛ>> Да и нет у меня неприязни к var.

AVK>Вот и не надо заниматься демагогией.



AVK>>>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.

КЛ>>Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь.

AVK>Хм, думал ты поймешь. Поясняю логическую цепочку: для записи сути алгоритма, если нам не нужно получить компилируемый код, обычно стараются придумать более простую как для формулирования, так и для чтения форму. Обычно в этой роли выступает псевдокод либо даже просто описание на естествененом языке. Так вот — в этих описаниях никто не аннотирует конкретные типы. Потому что это не требуется для описания сути.
AVK>Вот, например:
AVK>

AVK>

AVK>
1. Получаем объект автоматизации студии DTE.
   AVK>
2. Сканируем все активные проекты в открытом солюшене и выбираем те из них, которые являются проектами C#.
   AVK>
3. Находим среди них тот, output assembly которого совпадает с именем сборки.
   AVK>
4. Рекурсивно обходим все элементы проекта и находим среди них те, расширение файлов которых соответствует заданному.
   AVK>
5. Находим элемент проекта, соответствующий codebehind.
   AVK>
6. Находим имя первого типа в файле codebehind (стандартное поведение дизайнеров студии).
   AVK>
7. Сравниваем его с заданным.
   AVK>
8. Если совпало — возвращаемся к айтему-владельцу и открываем его в редакторе.
   AVK>

AVK>Это абсолютно исчерпывающее для понимания сути кода описание алгоритма. При этом ни одного типа в этом описании нет. Так вот, в идеале и код должен быть точно такой же.

Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска

КЛ>>попозже

AVK>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.

здесь

Автор: Константин Л.
Дата: 20.06.07

. Обрати внимание на закомментированные строки с явной аннотацией типов.

1. Поддержка студии была тогда почти никакой.
2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие

Вот, например, тебе файлик. Разберешься сходу с foreach?

КЛ>>восприятие кода и экспертная оценка — разные вещи.

AVK>Возможно. Но то, что ты назвал демагогией, как раз таки экспертная оценка и есть. Опирающаяся, разумеется, на мой опыт.

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

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

Не слишком ли загнул, м?

КЛ>> Вот попытка собсвенное восприятие подогнать под экспертную оценку

AVK>Аргументы, на основании которых ты заключил, что это так.

выше

КЛ>>, да еще и восприятие других людей под нее подогнать — демагогия.

AVK>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.

получается как умею. Однако ты свою правду объявил общей. Вот где подгон.

AVK>>>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.

КЛ>>аналогично

AVK>Ну и к чему тогда тут обсуждение личностей?

нету тут обсуждения личностей. тут обсуждение высказываний.

AVK>>>С моей стороны никакой демагогии пока нет.

КЛ>>ну я другого мнения и не ожидал

AVK>По делу есть что сказать?

по делу выше.

AVK>>>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?

КЛ>>и тебе можно, и мне можно. дело только в категоричности высказываний.

AVK>Категоричность высказываний — не повод называть эти высказывания демагогией.

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

КЛ>Допустим, тогда ты должен доказать, что это не личная неприязнь, а общеизвестный факт

Это ты должен доказывать. Ты же меня в личной неприязни обвинил.

КЛ>Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска

Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.

AVK>>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.

КЛ>здесь

Автор: Константин Л.
Дата: 20.06.07

. Обрати внимание на закомментированные строки с явной аннотацией типов.

КЛ>1. Поддержка студии была тогда почти никакой.
КЛ>2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
КЛ>3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие

КЛ>Вот, например, тебе файлик. Разберешься сходу с foreach?

Можно вместо двух экранов кода конкретный кусок прямо сюда привести?

КЛ>

КЛ>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.

КЛ>Не слишком ли загнул, м?

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

AVK>>Аргументы, на основании которых ты заключил, что это так.

КЛ>выше

Нету выше аргументов. Опять бездоказательный наезд.

AVK>>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.

КЛ>получается как умею.

Лучше тогда не стоит.

КЛ> Однако ты свою правду объявил общей. Вот где подгон.

И опять бездоказательный наезд.

AVK>>Ну и к чему тогда тут обсуждение личностей?

КЛ>нету тут обсуждения личностей.

А это просто вранье.

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

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?

AVK>Что тор, что я считаю экспертной оценкой на самом деле личная неприязнь.

На самом деле личные предпочтения, не более.

AVK>>>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.

КЛ>>по делу ты ничего не ответил

AVK>Ах вон оно как.

Именно так.

AVK>>>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?

КЛ>>конечно конечно

AVK>Ха ха ха. Вобщем понятно, за душой у тебя ничего нет, флеймишь впустую. На сем и закончим.

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

здесь. Обрати внимание на закомментированные строки с явной аннотацией типов.

1. Поддержка студии была тогда почти никакой.
2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие

2 раза просил. На третий соизволишь? Спасибо.

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

_FR>>Приведи пример кода, в котором из-за замены имени типа переменной на var ты не смог бы разобраться?

L>Это не совсем про читабельность, но все-таки.

L>В некоторых проектах ведется такая шняга, как tracability matrix. Суть ее в том, что каждый участок кода так или иначе связан с реализаций некоторых требований. Если в код были внесены какие-либо изменения, то тестеры могут отследить, какие требования могло затронуть это изменение и перетестировать, не сломалось ли чего.

Да, вопрос хороший и по делу.

L>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать.
L>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

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

По сути: не верю я, что если "по tracability matrix будет отслежено", то это принесёт хоть какую-то пользу. Посуди сам: равноправно замена может произвестись на полиморфный тип (что частенько случается, например, вместо Class1 метод стал возвращать более конкретный наследник Class1Derived), и тогда указанный тобой подход работать не будет: список изменённых файлов ничего не покажет.

Если уж опираться на tracability matrix (кстати, именно tracability или traceability matrix?), то получать её надо не "набором файлов, которые пришлось поменять что бы компилятор смог скомпилировать", а умной туловиной навроде решарпера, которая покажет, в каких файлах использовались изменённые члены класса. Туловина, кстати, смогла бы и рассчитать важность изменения для тестирования.

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

L>>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать.
L>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

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

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

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

L>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать.
L>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?

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

L>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

AVK>Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?

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

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

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

L>>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.

AVK>>Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?

L>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован.
L>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.

Вообще, несколько необычная практика. У вас автоматический тул, который строит зависимости и показывает что-то типа code coverage как unit tests? По-моему так сходу сложно оценить риски и необходимый охват.

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

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

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

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

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

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

L>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован.
L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился.

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

Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.

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

L>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован.
L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.

КЛ>Вообще, несколько необычная практика. У вас автоматический тул, который строит зависимости и показывает что-то типа code coverage как unit tests? По-моему так сходу сложно оценить риски и необходимый охват.

Лично мы, это не используем. Но я учавствовал в проекте, в котором заказчик хотел видеть в рамках какой user story был изменен файл. Эта информация бралась из Perforce-а.

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

L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.

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

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

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

Почему? В чем такой уж плюс? Или вы все под SourceSafe-ом сидите?

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

L>>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован.
L>>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился.

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

L>Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.

Формулировки не понял, можешь конкретнее написать?

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

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

L>>Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.

_FR>Формулировки не понял, можешь конкретнее написать?

string test() {
  return "";
}

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

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

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

Здравствуйте, 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 только там, где он не вносит неоднозначности по поводу типа переменной, т.е. либо если справа от "=" стоит вызов конструктора или приведение типа.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

здесь