1 Web описана в книге Дональда Кнута ""The WEB System of Structured Documentation" (Palo Alto: Stanford University Dept. of Computer Science, Report No.STAN-CS-83-980, 1983). Система CWeb описана в книге Дональда Е. Кнута и Сильвио Ливая "The CWeb System of Structured Documentation" (Reading: Addison Wesley, 1 994). Обе публикации не только описывают как работают эти системы, но

22. Программа без комментариев ничего не стоит

Программа, на написание которой затрачен год, может использоваться в течение 1 0 лет. Вам придется затратить на сопровождение гораздо больше денег, чем вы выделили на первоначальную разработку, а программа без комментариев несопровождаема. "Блестящий" программист, который втрое быстрее, чем другие, пишет короткий, элегантный, но некомментированный текст программы, вам обойдется дорого. Какому-то менее талантливому программисту придется затратить в 1 0 раз больше времени, чем нужно, устраняя неизбежные ошибки.

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

К счастью, писать можно легко научиться. Конечно, если вы придерживаетесь правила "Сделай сначала комментарии", то вам придется писать все свои комментарии до начала программирования.

23. Располагайте программу и документацию вместе

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

Если вам на самом деле нужна отпечатанная документация высшего качества, то вы можете воспользоваться чем-нибудь похожим на систему Web (для языка Паскаль) или CWeb (для языков Си и Си++) в комбинации с TeX1. я пользуюсь подобной системой под названием arachne, которая

хорошо демонстрируют это. В этих книгах документируются реальные тексты программ, реализующих указанные системы.

TeX является редакционно-издательской системой Кнута. Она имеется в нескольких коммерческих версиях.

была разработана мной для того, чтобы писать свою книгу "Compiler Design in C". (Arachne документирует тексты на Си и Си++, используя в качестве редактора troff). Все эти программы позволяют вам размещать исходный текст программы и документацию в одном файле. Вы можете выделить исходный текст для компиляции, или загрузить этот файл в текстовый процессор, чтобы напечатать единое руководство с исходным текстом и документацией. Эти системы позволяют осуществлять перекрестный поиск идентификаторов в программе и документации, позволяя вам прослеживать связи одной части программы с другой ("этот код используется вон там"), и так далее. Так как для получения печатной версии используется обычный текстовый процессор, то вы можете делать то, чего непросто добиться в комментариях - вставлять рисунки, например.

24. Комментарии должны быть предложениями

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

25. Пропустите свой исходный тест через систему проверки орфографии

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

26. Комментарий не должен подтверждать очевидное

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

++x; увеличить x

но мне также не нравятся комментарии типа:

I /*------------------------------------------------------**

2** **

3** ДАТА:2 9 февраля 2 0 00 г. **

4** ФУНКЦИЯ: **

5 ** equal **

6** **

7** АВТОР: **

8** Джозеф Эндрюс **

9** **

10 ** ОПИСАНИЕ: **

II ** Эта функция предназначена для сравнения двух строк **

12 ** на лексикографическое равенство.

13 **

14 ** ИСКЛЮЧЕНИЯ:

15 ** Функция не работает для строк Unicode. **

16 ** **

** **

/*-------------------------------------------

* Определения глобальных переменных:

*

Любой средний программист знает, как выглядит определение.

27. Комментарий должен предоставлять только нужную для сопровождения информацию

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

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

Листинг 1. Бесполезный заголовочный комментарий