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

A>Зато отлично похабит код! Нужно написать другую статью: Code Uglification Techniques. Туда войдут: Hungarian, if(0==value), (void)printf — для тех, кто любит указывать о явном опускании кода возврата, и другие дебильные приемчики, которые обожают некоторые программисты-недоучки

Еще недопущение возврата из середины , в результате чего рождаются уродцы вида:

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}

// ...

if ( bResult )
{
    // ...
    if ( somethingFailed ) bResult = false;
}
return bResult;

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

AV>Не всегда реально

Естественно, я согласен . Точно также можно сказать про unit-тесты — есть куча случаев когда разработка через тестирование не эффективна или даже просто невозможна. Кроме того, сама идея разработки через тестирование проста и интуитивно очевидна. Тем не менее, на эту тему написано куча статей и книг, есть специальные средства для унифицированной работой unit-тестами. Основная идея моего поста, что отладчик можно использовать не только как средства поиска багов, но и как инструмент разработки и предлагалось обсудить, когда это будет эффективно, когда нет. Кстати, логирование — это также один из вариантов отладки по большому счету. Можно расширить мысль — программа должна трассироваться на этапе разработки, логи также должны вестись и анализироваться на этапе разработки — не только для поиска багов, но и для контроля качества. Допустим, я пол-дня чего то писал, реализовал некоторый функционал. Собрал, запустил — вроде все работает, сел писать дальше. Вот здесь нужно было протестировать качество работы. Каким образом: запустить тесты ( с этим понятно ), я предлагаю в качестве еще одного инструмента использовать трассировку ( или логирование ). В чем плюс — при внимательной трассировке или изучении лога можно обнаружить баг сделанный на предыдущих итерациях или увидеть несовершенство алгоритма. Особенно, если этим будет заниматься в стиле XP не тот человек, который писал код, так сказать, свежий глаз. Кстати говоря, в последнем случае трассировка может быть совмещена с code-review.

Hi TarasCo

AV>>Не всегда реально

T>Основная идея моего поста, что отладчик можно использовать не только как средства поиска багов, но и как инструмент разработки и предлагалось обсудить, когда это будет эффективно, когда нет.

Если под отладчиком понимать то, что позволяет пройтись ручками по шагам по коду, то вряд ли это это возможно применять более-менее широко (скорее всего даже очень узкая ниша будет). Это связано с очень небольшой скоростью работы программиста в таком режиме. Человек слишком медленно работает, поэтому чем меньше он задействован (чем больше автоматизация), тем лучше. Оптимальный вариант, чтобы человек даже кода не писал, а только ставил задачи. Но на данном этапе это пока не реально, но надо стремиться как можно меньше задействовать человека.

T>Кстати, логирование — это также один из вариантов отладки по большому счету. Можно расширить мысль — программа должна трассироваться на этапе разработки, логи также должны вестись и анализироваться на этапе разработки — не только для поиска багов, но и для контроля качества. Допустим, я пол-дня чего то писал, реализовал некоторый функционал. Собрал, запустил — вроде все работает, сел писать дальше. Вот здесь нужно было протестировать качество работы. Каким образом: запустить тесты ( с этим понятно ), я предлагаю в качестве еще одного инструмента использовать трассировку ( или логирование ). В чем плюс — при внимательной трассировке или изучении лога можно обнаружить баг сделанный на предыдущих итерациях или увидеть несовершенство алгоритма.

При трассировке или логгировании вряд ли ты увидишь несовершенство. Тут как в старой русской поговорке. Слишком много низкоуровневых деталей перед глазами. Я вообще сторонник подхода при написании кода — день посидел и подумал, а потом за 5 минут написал. К такому подходу еще в школе приучил преподаватель информатики. Правда потом как-то увлекся использованием дебаггера. Но в последнем проекте (AppServer) нет возможности использовать дебаггер. А некоторые моменты даже логгированием нельзя проверить. Поэтому сначала много думаем, а потом мало пишем. И сравнивая свою производительность я увидел, что использование дебаггера только снижало производительность.

Все что описано, только личные наблюдения и мысли.

--
С Уважением

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

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

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

K>>>>Простой такой дедовский метод, но мне очень часто помогает.

L_L>>>
L_L>>>Отличный способ.

K>>Ну так, фирма веников не вяжет

>>> Тусил вот тут на одном форуме[...]

K>>У меня таких историй тоже много, помню текла память у меня, ну сидел с BoundsChecker'ом, маялся, чего то ничего не получалось, потом плюнул на это всё, начал просто комментировать куски кода пока не пропали утечки, потом начал раскомментировать пока не появились снова.В общем в течении часа нашёл источник утечек. В общем чо тут говорить — бинарный поиск — классика.

S>Мда.. Как говориться, кому лень читать манулы, тот просто "тыкает" пока не получиться . Есть другое название этому методу — "метод тыка" . Только это прокатывает в небольших проетах (аля нотэпада). А в серъезных проетах этот метод не поможет. А BoundsChecker и его потомок DevPartner — это то, чем нужно пользоваться. Один раз понять как и больше не будет желания комментировать.

На больших проектах BoundsChecker и его потомок DevPartner как раз и безполезены.
Баги в программе, помноженные на баги в DevPartner делают этот тул на больших проектах совсем бесполезным.

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

На данный момент, я исправил синтаксические ошибки. Над содержанием статей работа продолжается. Я учту все Ваши пожелания, и буду выставлять сюда новый материал для вашей оценки.

Я не ставлю перед собой цель написать исчерпывающее руководство по отладке или сделать из этого книгу. Поэтому материал не очень сильно систематизирован. Я буду подробней описывать те или иные моменты в следующих публикациях. Человека нельзя ничему научить, он может только сам захотеть. Я не буду все подробно разжевывать – кому надо тот приложит усилия, чтобы докопаться до сути. Я могу задать только направление. Мне приятно видеть, что некоторые участники форума открыли для себя что-то новое. Сейчас я просто стараюсь выдать то, что накопилось у меня в голове. Первые 4 части, которые я представил, это только начало. В планах писать об отладке COM, сервисов, DLL, DirectShow фильтров и т.п. Я буду считать свою задачу выполненной, если моя работа кому ни будь пригодиться. О чем бы Вам было интересно почитать?

Если у кого-то возникнет желание систематизировать весь материал и довести до ума – милости прошу. Пишите, обсудим.

PS: Я выложил еще одну статью про виртуальные списки на базе CListCtrl. Думаю, что новичками будет полезно. http://www.devdoc.ru/index.php/content/view/v_clistctrl.htm