OberonCore

Да, но это означает, что ещё есть какое-то недоверие к логической верификации программ. А раз так, то зачем вообще верифицировать программы?

Характерно для абсолютизированной логики: либо все, либо ничего.
А ведь суть сказанного info21 проста: если вы правильно строите программу, ее и отлаживать легче, и тестировать приятнее.
Необходимость в тестировании остается, т.к. человек несовершенен, ему свойственно ошибаться. Но найти потерянный винтик легче на чистом полу, чем в большой куче мусора.

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

Вообще говоря, не означает. Может я просто хочу насладиться списком сообщений "Test #1 - OK".

Ха-ха! Вы получаете удовольствие только от того, чему не доверяете? % ))

Согласен. IMHO, именно этот этап можно и нужно максимально автоматизировать ("пусть ошибка расскажет о себе сама").
Впрочем, иногда задумчивое многочасовое щелкание мышкой в отладчике - хороший предлог для небольшой релаксации на работе ("Как что я делаю?! Не видишь разве - багу правлю!!"). Наденешь наушники, включишь плеер и - дрожите, ошибки! Сейчас я до вас доберусь, сейчас... сей-час... сей... хр-р...

По-моему, такой момент удовольствия реально присутствует.

<это для Geniepro, если кто не понял:>
Создание батареи тестов есть часть разработки.
Чтобы обеспечить будущее развития.

Успешно прогнать батарею тестов на тщательно построенной программе -- значит, убедиться в правильности тестов (тесты = форма кодификации требований).

Кент Бек. Экстремальное программирование. (Глава 9. Обратно к истокам)Там большой хороший отрывок о том, почему тесты и полезны, и приятны. Рекомендую.

Может быть, если кишки изначально делать как-то модульно-компонентно-интерфейсно, то поиск багливых кусков будет проще? (это мысль вообще, а не про конкретную уже кем-то написанную систему, которую без отладчика отлаживать очень трудно)

Кишки не интересны, если они работают как положено. Чему сильно способствуют правильные циклы.

От опечаток. Доп. проверка граничных ситуаций. И т.п.
Верный расчёт любой инженерной конструкции не отменяет приёмо-сдаточных испытаний.

Боюсь, что мои ожидания будут отличаться от ожиданий ваших пользователей, так как опускаться к железке мне приходится очень редко. Но если интересно, то вот основные сценарии, для которых я использую отладчик:
1) Точки останова с изучением того, как программа дошла до этих точек.
2) Останов программы по исключительной ситуации. В BB это уже есть в виде трапа по всяким ASSERT.
3) Выяснение какая зараза поганит стэйт. Этот сценарий, к счастью, появляется крайне редко - при ковырянии в чужих сишных либах. Тем не менее, что делать в таких случаях без дебагера я не знаю.

Наверное мне повезло Мне не приходилось ловить баги в неправильных циклах, поэтому мне непонятна вся эта шумиха вокруг правильных циклов.

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

Но где гарантия, что бага будет исправлена, если изначально нет уверенности, что алгоритмы строились правильно?

Гарантию вам никто не даст, даже оберон Но вот максимальную уверенность, лично мне, дают тесты. И если будет код с кучей break'ов и покрытый тестами, и код с "правильными" циклами от самого Вирта, но без тестов - то мой выбор будет однозначно в пользу тестов

P.S. Я уже говорил, 99% алгоритмов придуманы до нас, отлажены и положены в библиотеку. Можетет не верить, но я уже давно не писал циклов на C++. Потому что есть std::for_each (с успехом заменеят for), std::find_if (с успехом заменяет while) и еще сколько-то простых алгоритмов, к которым сводятся самые наворочные и непонятные циклы.

Я прекрасно Вас понимаю. Я сам работаю с программами, в которых подавляющее большинство циклов тривиально. Так же, как Вы используете итерирование foreach и поиск search, так и я - полный проход линйеный поиск. И "наворочные и непонятные" циклы в этом случае строит только тот, кто не видит этих паттернов ("для каждого" и "существует-найдём"). Поэтому применительно к данным задачам воспринимайте фразы о правильном построении как то, что человек не клепает "неповторимые велосипеды", а чётко различает и реализовывает эти паттерны.

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

Касательно тестов - никто их не отменяет. Просто сами по себе они ничего не гарантируют.

В программах даже нашего с Вами типа можно быть уверенным только в том случае, если они разработаны постепенным разбинием "сверху вниз", где суть каждого уровня очевидна. В частности, вышеназванный поиск и проход иногда раскручивается от сформулированного мат. предиката с кванторами E(xists) и A(ny). Типа, из одного алгоритма с матрицами (студенты у меня решали сегодня) - это одна из "листовых" процедур, до которых доразбили задачу:

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

Вместо:
Хотя, кажется, так слегка менее наглядно... Зато "правильно", по-Обероновски-07.

По-моему, как раз это более наглядно.

(А И.Е. позор за такой код.)