Здравствуйте, Lloyd, Вы писали:
IT>>Для начала следует определиться понимаем ли мы одно и тоже под термином code review. L>Во всех командах, где мне доводилось работать, под "code review" понималась регулярная проверка кода, измененного за определенный промежуток времени. Для этого тех. лид просматривал дифы, внесенные его коллегами за последние день-два-три.
Во всех командах, где мне доводилось работать, под 'code review' понимался переодический критический разбор кода, на предмет анализа дизайна, применения паттернов, следования соглашениям.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
L>>Это не мусор, это аннотация типа, которая часто при ревью позволяет увидеть потенциальные проблемы.
VD>Если проблема видна только с аннотациями тиов локальных переменных, то код является помойкой и ждать что-то хорошее от него я бы не стал.
Я уже приводил код:
var customers = GetCustomers();
if (customers.Any()) {
grid.DataSource = customers;
grid.DataBind();
} else {
// ...
}
Здравствуйте, IT, Вы писали:
L>>Во всех командах, где мне доводилось работать, под "code review" понималась регулярная проверка кода, измененного за определенный промежуток времени. Для этого тех. лид просматривал дифы, внесенные его коллегами за последние день-два-три.
IT>Во всех командах, где мне доводилось работать, под 'code review' понимался переодический критический разбор кода, на предмет анализа дизайна, применения паттернов, следования соглашениям.
И? Значит в твоем варианте отсутствие аннотаций может быть и подойдет, но в моем-то — нет.
Здравствуйте, Lloyd, Вы писали:
IT>>Здесь будет таже проблема, о которой ты говоришь.
L>Абсолютно верно. И как это относится к наличию аннотации типа у переменной? L>Или тот факт, что проблема не может быть решена глобально, означает, что ее не стоит решать даже там, где это возможно?
Она может быть решена глобально. Просто не используй цепочки вызовов, заводи под каждое возвращаемое значение свою переменную. Лишний мусор же для тебя фигня.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, igna, Вы писали:
VD>>Нет.
I>В чем же две большие разницы?
В одном случае речь идет о внутренней реализации некой функции и типах выводимых компилятором во время компиляции этого кода. В другом о неких публичных структурах типы в которых заменяются семволами и становятся известны только при воплощении шаблона с подстановочными парамтрами вместо символов.
Я вообще нахожу тут мало общего. В одном случае нет публичного интерфейса, в другом вывода типов.
I>
I>template <class T>
I>void f(T const& t)
I>{
I> // оперируем "более абстрактным интерфейсам" t,
I> // в который входят только те функции,
I> // что были применены внутри f
I>}
I>
Разница в том, что в случае вывода типов типы будут проверены при компиляции и стало быть ошибок типов быть не может. А в случае С++ типы при разборе шаблона не проверяются вообще.
Тут уж скорее была бы уместна аналогия с выводом типов в ML-подобных языках (ОКамл, Хаскель).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Хрен ее знает, тебе конкретика нужна? Посмотри примеры в MSDN, где сплошь и рядом создаваемый FileStream присваивается переменной того же типа, хотя переменная эта вполне могла бы иметь тип Stream.
Это как раз говорит о том, что программистам по сути по фигу какой там тип у этой переменной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>>>Здесь будет таже проблема, о которой ты говоришь.
L>>Абсолютно верно. И как это относится к наличию аннотации типа у переменной? L>>Или тот факт, что проблема не может быть решена глобально, означает, что ее не стоит решать даже там, где это возможно?
IT>Она может быть решена глобально.
Нет, она не может быть решена гловально. т.к. есть еще анонимные типы.
IT>Просто не используй цепочки вызовов, заводи под каждое возвращаемое значение свою переменную. Лишний мусор же для тебя фигня.
Там где это критично, там я завожу. В общем случае, заведение доп. переменной порождает лишний "шум" и это перевешивает достоинства наличия аннотации.
Здравствуйте, Lloyd, Вы писали:
IT>>>>Покажи мусор в коде с var, которого нет в коде с явным указанием типов. L>>>Покажи мусор в коде без var.
IT>>
IT>>IEnumerable<Customer> customers = GetCustomers();
IT>>^^^^^^^^^^^^^^^^^^^^^ <- мусор здесь
IT>>
L>Это не мусор, это аннотация типа, которая часто при ревью позволяет увидеть потенциальные проблемы.
Это никому не нужный мусор, который некоторые выдают за возможность увидеть потенциальные проблемы.
IT>>У тебя проблема не только с примерами, но ещё и с памятью.
L>Да, старею. совсем плохой стал. L>Тебя не затруднит мне немощному еще раз привести тот мега-пример, который ты якобы приводил? Ну пожалуйтса.
Я тоже старею. Уже на лишние телодвижения не хватает сил.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Lloyd, Вы писали:
IT>>Во всех командах, где мне доводилось работать, под 'code review' понимался переодический критический разбор кода, на предмет анализа дизайна, применения паттернов, следования соглашениям.
L>И? Значит в твоем варианте отсутствие аннотаций может быть и подойдет, но в моем-то — нет.
Видимо так. Если задача бэбиситить девелоперов и каждые три дня проверять всё, что они понаписали, то наверное лучше использовать аннотации. Да и вообще, что-нибудь попроще.
Если нам не помогут, то мы тоже никого не пощадим.
Она здесь есть.
VD>Если она внутри DataSource или DataBind(), то там ее и нужно устранять.
Хорошо, пример попроще:
var customers = GetCustomers();
if (customers.Any()) {
Console.WriteLine(customers.First().Name);
}
Только не говори, что проблема в Console.WriteLine.
VD>Есть такое простое правило нельзя принимать тип более общий чем требуется. Если оно нарушается, то можно долго искать ошибки там где их нет.
IT>>>IEnumerable<Customer> customers = GetCustomers();
IT>>>^^^^^^^^^^^^^^^^^^^^^ <- мусор здесь
IT>>>
L>>Это не мусор, это аннотация типа, которая часто при ревью позволяет увидеть потенциальные проблемы.
IT>Это никому не нужный мусор, который некоторые выдают за возможность увидеть потенциальные проблемы.
Это не мусор, это аннотация типа, которая часто при ревью позволяет увидеть потенциальные проблемы.
Продолжим дальше сию увлекательную беседу?
IT>>>У тебя проблема не только с примерами, но ещё и с памятью.
L>>Да, старею. совсем плохой стал. L>>Тебя не затруднит мне немощному еще раз привести тот мега-пример, который ты якобы приводил? Ну пожалуйтса.
IT>Я тоже старею. Уже на лишние телодвижения не хватает сил.
У тебя, видимо процесс старения зашел гораздо дальше — появляются воспомнинания о том, чего не было. Эх. мне б такое, жизнь стала бы куда интереснее.
L>Только не говори, что проблема в Console.WriteLine.
А какая здесь проблема то? Какой-то урод написал кривую коллекцию?
VD>>Есть такое простое правило нельзя принимать тип более общий чем требуется. Если оно нарушается, то можно долго искать ошибки там где их нет.
L>Где это правило тут нарушается?
А где тут проблема? Два раза энумератор запросили что ли?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
L>>И? Значит в твоем варианте отсутствие аннотаций может быть и подойдет, но в моем-то — нет.
IT>Видимо так. Если задача бэбиситить девелоперов и каждые три дня проверять всё, что они понаписали, то наверное лучше использовать аннотации.
Бэбиситить можно не только девелоперов, но и себя самого. Особенно умиляет смотреть на свой же код 2-3-летней давности.
IT>Да и вообще, что-нибудь попроще.
Здравствуйте, VladD2, Вы писали:
L>>В общем случае, заведение доп. переменной порождает лишний "шум" и это перевешивает достоинства наличия аннотации.
VD>Шум ты создаешь описявая явно типы там где в этом нет смысла.
"там где в этом нет смысла" аннотацию типов писать нет смысла. Вы правы, кэп.
VD>А переменная дает имя значению. Иногда это очень даже способствует чтению кода.
А иногда — нет.
VD>А уж для отладки — это полезно всегда и без каких либо условий.
Здравствуйте, VladD2, Вы писали:
VD>Я вообще нахожу тут мало общего. В одном случае нет публичного интерфейса, в другом вывода типов.
И фиг с ним. Тем не менее твое "если мы не указываем типы внутри методов, то мы оперируем их более абстрактными интерфейсами. В эти интерфейсы входят только те методы, что были применены внутри тела метода" вполне относится и к шаблонам функций C++.
VD>Разница в том, что в случае вывода типов типы будут проверены при компиляции и стало быть ошибок типов быть не может.
Так ведь и в случае использования шаблонов C++ "типы будут проверены при компиляции и стало быть ошибок типов быть не может".
VD>А в случае С++ типы при разборе шаблона не проверяются вообще.
Ну при инстанцировании проверяются. Хрен с редькой...
Если нам не помогут, то мы тоже никого не пощадим.
