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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Библиотеки, как правило, лучше продуманы и протестированы, чем ваши собственные программы.

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

Скомпилируйте программу. Разумеется, для этого понадобится компилятор. Его сообщения обычно весьма полезны, даже если мы хотели бы лучшего, и если вы не профессионал, то должны считать, что компьютер всегда прав. Если же вы реальный эксперт, то закройте книгу — она написана не для вас. Иногда программисту кажется, что правила компилятора слишком тупые и слишком строгие (как правило, это не так), и многие вещи можно было бы сделать проще (как бы не так). Однако, как говорится, “свой инструмент проклинает только плохой мастер”. Хороший мастер знает сильные и слабые стороны своего инструмента и соответственно его настраивает. Рассмотрим наиболее распространенные ошибки компиляции.

• Закрыта ли кавычка строки литералов?

• Закрыта ли кавычка отдельного литерала?

• Закрыта ли фигурная скобка блока?