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

21. Пишите программу с учетом сопровождения - вы специалист по сопровождению

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

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

Вы можете переформулировать настоящее правило таким образом: Не умничайте. Искусный код почти невозможно сопровождать.

21.1. Эффективность - часто просто пугало

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

выполняться медленно вне зависимости от того, насколько хорошо она запрограммирована.

Часть

Форматирование и документация

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

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

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