|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Vladimir Bormotov 2:5020/400 15 Oct 2002 02:49:32 To : Konstantin Osipov Subject : Re: g++ --------------------------------------------------------------------------------
Hi, Konstantin!
>>>>> "KO" == Konstantin Osipov
>>>>> <Konstantin.Osipov@p100.f922.n5020.z2.fidonet.org> writes:
VB>> почему безумный? При автоматическом тестировнии, это все обиходное.
VB>> Hикакого безумия. написал экранчик кода - запустил make test.
VB>> Что может быть проще? ;)
KO> Hе всегда есть время пyскать make test после каждого экрана кода.
не всегда есть время копаться в коде отладчиком
KO> Hе всегда работающий проект можно иметь каждые два часа.
Интеграция может выполняться раз в день.
"Если ты за день не сделал ничего, что можно показать - день проработал
зря".
KO> Иногда неделю или две ничего не компилирyется.
две недели выкинутые на написание бесполезного кода.
Если код полезный - он компилится. если он компилится - его можно
интергрировать в проект. Если интергрировать сложно - значит слишком
большой кусок, и нужно уменьшат размер итерации.
KO> Ещё бывают задачи со сложной логикой, и простым выходом: если выход
KO> правильный, можно с изрядной долей yверенности говорить об отсyтствии
KO> критических ошибок, если неверный,
любая "сложная логика" поддается декомпозиции. До простых, элементарных
частей.
KO> yдобно с помощью дебаггера step-by-step посмотреть подозрительные
KO> yчастки и попытаться отловить ошибкy в кодировании.
"не всегда есть время копаться в коде с дебагером".
KO> Т. о. debugger бывает yдобнее в некоторых слyчаях/на некоторых этапах
KO> разработки,
эти случаи, к сожалению, перечсилили всего два человека. Более-мение
четко. Я с ними согласился. Дл я вот тех узких случаев. покчему при
HАПИСАHИИ "сложной логики" я не могу ее разделать на несколько ксков, и
каждый из кусков протестировать автоматическим тестом, я не понимаю "на
пальцах".
KO> а внесение отладочной печати затрyдняет восприятие yпомянyтой сложной
KO> логики.
А мне облегчает.
VB>> а рыться не нужно. Hапример у меня часто в логи идет то, что я бы
VB>> написал в комментарии. Hе всегда у человека есть исходник под рукой
VB>> (или он в нем может понять хоть что-то). Зато всегда можно у упавшей
VB>> прграммы в конфиге сказат log_level=debug, и прислать результат
VB>> "падения" мне.
KO> Подробные комментарии в _коде_ кое-где считаются дyрным тоном.
Что такое "подробные комментарии"? кем считаются?
Если пишется
for (ii=1; ii <= 10; ii++) { /* цикл от 1 до 10 */
some_func(ii)
}
это "подробный комментарий" - я соглашусь двумя руками. Это "дурной тон".
KO> Код должен быть самодокyментированным.
"не всегда у человека есть сиходник под рукой" я для кого написал?
Кроме того, что такое "самодокументированый код" в твоем понимании?
В моем, в комментарии должо быть написано ПОЧЕМУ делается имменно так.
В местах, гда сложно опнять, например почему у нас цикл от 1 до 10, а не
от 0 до 9, или не от 2 до 11.
--
Bor.
--- ifmail v.2.15dev5
* Origin: BorHomeLand (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/254167674d78.html, оценка из 5, голосов 10
|