ветственный программист должен принять для этого меры. Наше глав% ное оружие – защитное программирование и правильное тестирование. В данной главе мы посмотрим, какие успешные технологии отладки можно применить, если ошибки все же проскользнут в программу.

Природа этого зверя

Вопреки распространенному мнению термин жучок (bug) был в ходу еще до появления компьютеров. В 1870%х годах Томас Эдисон говорил о жучках в электрических цепях. История с релейной вычислительной машиной Mark II Aiken Гарвардского университета является первым зарегистрированным случаем компьютерного жучка. В 1945 году, ко% гда первые компьютеры были таких размеров, что занимали целую комнату, в одно такое помещение залетела бабочка и, сев на какие%то провода, вызвала аварию системы. В журнале оператора была сделана запись о первом реальном случае обнаружения компьютерного жучка. Это событие увековечено экспонатом Смитсоновского института.

«Баги» – неприятная вещь. Но что, в сущности, они собой представля% ют? Номенклатуру этих явлений мы привели в разделе «Терминоло% гия» на стр. 184. Полезно определить, какие разновидности багов встречаются, выяснить, откуда они берутся, как им удается сохра% ниться и как от них можно избавиться.

Взгляд с высоты птичьего полета

Программные ошибки распадаются на несколько крупных категорий, знание которых облегчит дальнейшие действия. Природа некоторых ошибок такова, что их труднее отыскать, и это связано с тем, к какой категории они относятся. Слегка отстранившись и прищурясь, мы об% наружим следующие три класса ошибок:

Сбой при компиляции

Крайне досадно, когда код, на который вы потратили столько вре% мени, отказывается компилироваться. Это значит, что вам придется вернуться и исправить противную маленькую опечатку или несоот% ветствие типов параметров, а затем снова компилировать и только потом приниматься по%настоящему тестировать свой труд. Как ни странно, это лучший тип ошибок, с которым вы можете столкнуть% ся. Почему? Просто потому, что их проще всего обнаружить и ис% править. Они проявляются сразу и наиболее очевидны.1

Чем дольше поиск ошибок, тем дороже их исправление; это проил% люстрировано в разделе «Экономика ошибок» на стр. 216. Чем рань% ше вы сможете найти и исправить каждую ошибку, тем скорее вы

1При условии, что у вас правильно налажена среда компиляции, которая останавливается при обнаружении ошибки и дает разумные диагностиче%

ские сообщения.

После устранения ошибок компиляции у вас появляется исполняе% мый модуль, который вы и запускаете. Через некоторое время он аварийно завершает работу. Вы тихо ругаетесь и вините во всем не% чистую силу. После 60%й аварии вы грозитесь выкинуть компьютер в окошко. Бороться с такими ошибками значительно труднее, чем с ошибками компиляции, но все же достаточно просто.

Причина в том, что, как и ошибки компиляции, эти ошибки вопию% ще очевидны. С программой, которая перестала выполняться, не поспоришь. Нельзя сделать вид, что авария – это «функция». По% сле того как программа откинула копыта, можно вернуться и поду% мать, где она пошла неверным путем. Легче, когда вы знаете, какие данные были введены перед сбоем и что сделала программа перед тем, как аварийно завершиться. Дополнительные сведения можно получить с помощью специальных инструментов (о чем ниже).

Неожиданное поведение

Это действительно неприятно, когда ваша программа не отправи% лась в мир иной, но ее явно понесло куда%то не туда. Вдруг она на% чинает делать непредсказуемые вещи. Вы ждете голубой квадрат, а появляется желтый треугольник. Код выполняется как ни в чем ни бывало, нимало не смущаясь вашим отчаянием. Откуда взялся желтый треугольник? Может быть, программу разрушили полчи% ща воинственных COM%объектов? Почти наверняка окажется, что где%то в недрах кода, выполнявшегося полчаса назад, есть мелкая логическая ошибка. Удачи вам в поиске.

Сбой может появиться в результате одной неверной строки кода, а мо% жет возникнуть тогда, когда будут объединены друг с другом несколь% ко взаимодействующих между собой модулей, исходные предположе% ния которых не вполне совместимы.

Взгляд с поверхности земли

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

Синтаксические ошибки

Обычно их перехватывает компилятор во время сборки, но некото% рые грамматические ошибки проскакивают незамеченными. В ре% зультате программа ведет себя странно и непредсказуемо. В языках типа C часто встречаются такие синтаксические ошибки:

•В условных выражениях вместо == пишут = или вместо && ставят &

•Забывают точку с запятой или ставят ее в неверном месте (клас% сический случай – после оператора for)

•Забывают заключать группу операторов цикла в фигурные скобки

•Нарушают парность круглых скобок

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

Компилируйте код при включенном выводе компилятором всех предупреди& тельных сообщений. Тем самым вы обнаружите потенциальные проблемы раньше, чем столкнетесь с ними реально.

Ошибки сборки

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

Я несколько раз сталкивался с такой ситуацией: система сборки не выполняла повторную компиляцию программы или общей библио% теки (возможно, из%за отсутствия в make%файлах необходимых зави% симостей или влияния временной метки старого выполняемого фай% ла). И всякий раз, тестируя сделанные мной модификации, я, неве% домо для себя, продолжал выполнять старый, содержащий ошибки код. Обмануть систему сборки можно разными способами, но хуже всего, если вы не заметите, что она сработала неправильно – как по% раженная проказой конечность.

Иногда это обнаруживается достаточно поздно. Поэтому, если у вас есть хоть какие%то подозрения, разумно полностью очистить проект и выполнить сборку с самого начала. Это должно устранить воз% можные проблемы системы сборки.1

1Предполагается, что вы уверены в средствах чистки своей системы сборки. Для полной надежности удалите весь проект и загрузите его заново из сис% темы контроля версий. Либо можно вручную удалить все промежуточные объектные файлы, библиотеки и исполняемые модули. В больших проек%

тах оба варианта крайне утомительны. C’est la vie.