190 Глава 9

пирование и отладка

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

Если вы регистрируете ошибку, источник которой не обнару­живается, то убедитесь в том, что вы используете корректный исходный текст программ. При объединении вместе больших систем почти всегда используется раздельная компиляция. Это может легко привести к ситуации, когда объектный код, содержа­щий ошибку, не соответствует исходному тексту программы, в котором вы пытаетесь ее отыскать. Особенно неприятный вариант возникает в том случае, когда компилятор или операционная система были изменены. Если поведение вашей программы не изменилось, а вы абсолютно уверены в том, что сами никаких изменений не вносили, то проверьте, не используете ли вы модуль, скомпилированный на другой версии операционной системы.

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

После того как вы обнаружили ошибку, попытайтесь понять, почему вы ошиблись в этом месте программы. Была ли это опе­чатка, или незнание языка программирования, или это указывает на какую-то логическую проблему? Уяснение причины ошибки поможет вам исправить программу. Это также может помочь обнаружить другие ошибки и не допустить ряда ошибок в бу­дущем.

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

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

fe Если вы решили сделать изменения, то должны просмотреть все ветвления в программе. Убедитесь в том, что внесенное изме­нение действительно решит проблему, а не породит ряд новых. рСамыми труднообнаруживаемыми ошибками являются те, которые ^•носятся в процессе исправления других. Это обусловлено тем, "что в процессе таких исправлений мы не столь систематичны,

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

9.5. Защитное программирование

Для борьбы с будущими ошибками рекомендуется программи­ровать с защитой. Каждый хороший программист должен учиты­вать возможность появления ошибок. Предположим, что ваша программа будет вызвана с неправильными данными, что файлы, предполагающиеся открытыми, окажутся закрытыми, и т. д. Составляйте свою программу таким образом, чтобы подобные ошибки сразу же дали о себе знать. В языке CLLI имеется боль­шинство общепринятых защитных средств подобного рода. Более того, в языке CLLJ производится полная проверка типов данных, контроль на выход за границы массивов и проверка на арифмети­ческое переполнение и потерю значимости как на этапе компиля­ции, так и на этапе выполнения. К двум защитным методам, которые отсутствуют в языке CLU, относятся проверка выпол­нения требований процедур и инвариантов представления, а также полное тестирование всех условных выражений. Нарушение инварианта представления или требований процедуры часто является первой причиной ошибки. Если в программу включены средства неявной проверки этих требований, то первый заметный симптом ошибки будет обнаружен значительно раньше. Рассмо­трим, например, процедуру со следующей спецификацией:

in_ range == proc(x, у: int, a: elem.array, e; elem) returns (b: bool)

requires у ,5 x.

effects Возвращается значение true, если e есть элемент из a hi, .,., а [у], т.е. b= дг [x^z^y & a [z ] =e ]