Читаем Программирование. Принципы и практика использования C++ Исправленное издание полностью

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

<p id="AutBody_Root081"><strong>5.9. Отладка</strong></p>

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

Итак, написав определенную программу, вы должны найти и удалить ошибки. Этот процесс обычно называют отладкой (debugging), а ошибки — жучками (bugs). Иногда говорят, что термин жучок возник в те времена, когда аппаратное обеспечение выходило из строя из-за насекомых, случайно заблудившихся среди электронных ламп и реле, заполнявших комнаты. Иногда считают, что этот термин изобрела Грейс Мюррей Хоппер (Grace Murray Hopper), создатель языка программирования COBOL (см. раздел 22.2.2.2). Кто бы ни придумал этот термин пятьдесят лет назад, ошибки в программах неизбежны и повсеместны. Их поиск и устранение называют отладкой (debugging).

Отладка выглядит примерно так.

1. Компилируем программу.

2. Редактируем связи.

3. Выполняем программу.

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

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

while (программа не будет выглядеть работоспособной) { // псевдокод

  Бегло просматриваем программу в поисках странностей

  Изменяем их так, чтобы программа выглядела лучше

}

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

Основной вопрос отладки звучит так:

Как понять, что программа действительно работает правильно?

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

<p id="AutBody_Root082"><strong>5.9.1. Практические советы по отладке</strong></p>

  Подумайте об отладке, прежде чем напишете первую строку своей программы. Когда написано много строк, уже слишком поздно пытаться упростить отладку. Решите, как сообщать об ошибках. По умолчанию в этой книге принят следующий принцип: “Использовать функцию error() и перехватывать исключение в функции main()”.

  Старайтесь, чтобы программу было легко читать.

• Хорошо комментируйте свою программу. Это не значит просто: “Добавьте много комментариев”. Вы не можете сформулировать смысл операции на естественном языке лучше, чем на языке программирования. В комментариях следует ясно и коротко указать то, что невозможно выразить в коде.

• Название программы.

 • Цель программы.

 • Кто написал программу и зачем.

 • Номера версий.

 • Какие фрагменты кода могут вызвать сложности.

 • Основные идеи.

 • Как организован код.

 • Какие предположения сделаны относительно вводных данных.

 • Каких фрагментов кода пока не хватает и какие варианты еще не обработаны.

• Используйте осмысленные имена.

 • Это не значит: “Используйте длинные имена”.

• Используйте логичную схему кода.

 • Ваша интегрированная среда программирования может помочь, но она не может сделать за вас всю работу.

 • Воспользуйтесь стилем, принятым в книге.

• Разбивайте программу на небольшие фрагменты, каждый из которых выражает определенную логическую операцию.

 • Старайтесь, чтобы функция не превышала больше одной-двух страниц; большинство функций будет намного короче.

• Избегайте сложных выражений.

Перейти на страницу:

Похожие книги

Programming with POSIX® Threads
Programming with POSIX® Threads

With this practical book, you will attain a solid understanding of threads and will discover how to put this powerful mode of programming to work in real-world applications. The primary advantage of threaded programming is that it enables your applications to accomplish more than one task at the same time by using the number-crunching power of multiprocessor parallelism and by automatically exploiting I/O concurrency in your code, even on a single processor machine. The result: applications that are faster, more responsive to users, and often easier to maintain. Threaded programming is particularly well suited to network programming where it helps alleviate the bottleneck of slow network I/O. This book offers an in-depth description of the IEEE operating system interface standard, POSIX (Portable Operating System Interface) threads, commonly called Pthreads. Written for experienced C programmers, but assuming no previous knowledge of threads, the book explains basic concepts such as asynchronous programming, the lifecycle of a thread, and synchronization. You then move to more advanced topics such as attributes objects, thread-specific data, and realtime scheduling. An entire chapter is devoted to "real code," with a look at barriers, read/write locks, the work queue manager, and how to utilize existing libraries. In addition, the book tackles one of the thorniest problems faced by thread programmers-debugging-with valuable suggestions on how to avoid code errors and performance problems from the outset. Numerous annotated examples are used to illustrate real-world concepts. A Pthreads mini-reference and a look at future standardization are also included.

David Butenhof

Программирование, программы, базы данных