Важнейшая технологическая задача, возникающая в процессе программирования, — соответствие единому стилю программирования. Под стилем программирования обычно понимают [Тассел 1985] набор приемов или методов программирования, которые используют опытные программисты, чтобы получить правильные, эффективные, удобные для применения и легко читаемые программы. Правила хорошего стиля — результат соглашения между опытными программистами. Обычно принципы хорошего стиля программирования являются результатом здравого смысла, исходящего из опыта. Это не набор обязательных правил, установленный раз и навсегда. Брайан Керниган (Вгiап Кernighan) и Роб Пайк (Rob Pike) [Керниган, Пайк 2001] уточняют, что код должен быть прост и понятен, т. е. обладать следующими свойствами:
* очевидная логика;
* естественные выражения;
* использование соглашений, принятых в языке разработки;
* осмысленные имена;
* аккуратное форматирование;
* развернутые комментарии;
* отсутствие хитрых трюков и необычных конструкций.
Правило стандартизации стиля заключается в том, что если существует более одного способа сделать что-либо и выбор произвольный, то следует остановиться на одном способе и всегда его придерживаться. Особое значение имеет единый стиль программирования в процессе работы над программным текстом в коллективных разработках. В большинстве крупных проектов существуют внутренние документы, определяющие стиль программирования команды разработчиков. Известным примером является документ по стилю программирования разработок GNU (http://www.gnu.org/prep/standards_toc.html). Применение таких документов приводит к использованию единого стиля, а следовательно, к повышению читабельности и сопровождаемости программ, а во многих случаях и предотвращению большого класса ошибок. Обратим внимание на то, что есть универсальные рекомендации, а есть рекомендации, связанные с конкретными языками.
Приведем некоторые рекомендации по стилю написания программ на язы ках С и С++, сгруппировав их в тематические классы. Многие рекомендации имеют обоснование — в некоторых случаях строгое, в других — слабое.
Структура файлов
Приведем рекомендации по именованию файлов.
* Заголовочные файлы должны иметь расширение h Файлы с программой на языке С должны иметь расширение с, а с программой на языке С++ — сс (в операционной системе Unix) или срр (в операционной системе Windows).
* Имена файлов ДОЛЖНЫ отличаться уже первыми восемью символа Обоснование: Некоторые устаревшие, но, тем не менее, широко используемые операционные системы накладывают ограничения на длину имени файлов.
* Все файлы должны иметь различные имена, даже если они находятся в разных каталогах.
Опишем рекомендации по длине строк.
* Строки не должны быть длиннее 80 символов. Обоснование: Многие текстовые редакторы и системы печати текстов программ ориентирована именно на это максимальное количество символов в строке. Исторически это объясняется текстовым режимом отображения символов на экране 25 строк по 80 символов.
* Лучше всего, если длина строк программы значительно короче 80 символов.
далее представлены рекомендации по организации файлов.
* Следует соблюдать следующий порядок в заголовочных файлах программы на языке С++:
* комментарий к файлу, который оформляется как блочный комментарий. Комментарий может начинаться указанием на лицензию, которая определяет права собственности на данный файл. Комментарий обычно продолжается идентификационной строкой системы управления версиями файлов. Например, для утилиты SССS строка может выглядеть так: %Z %M% %I% %E% и включать символ идентификации SССS, имя файла, номер версии и дату последней идентификации. Комментарий должен содержать краткое описание файла
• защитная проверка, гарантирующая компиляцию данного файла о единственный раз, вне зависимости от числа его включений в мод компиляции. Она должна выглядеть так:
#if !defined(FILENAME_H)
#define FILENAME_H
• импортируемые интерфейсы. Как правило, они определяются с помощью #iпсlude – директив;
• объявления;
• завершающая защитную проверку директива условной компиляции
#endif
** Для файлов кода на языке С++ рекомендуется такая последовательность
• комментарий к файлу;
* импортируемые интерфейсы,
• локальные объявления;
• экспортируемые определения.
Лексические соглашения
Приведем рекомендации по написанию идентификаторов.
* Не начинайте и не заканчивайте идентификаторы символом подчеркивания.
* Не используйте идентификаторы, состоящие только из прописных букв. Исключения составляют имена констант и макроопределений.
* Не следует в одной и той же программе использовать имена, различающиеся лишь написанием букв — строчной или прописной.
* Разделяйте части идентификаторов символом подчеркивания, а не написанием с большой буквы очередной части идентификатора.
* Идентификаторы должны начинаться со строчной буквы.
Опишем соглашения об именовании.
*Смысл всех имен должен быть понятен при чтении программы.
* Имена, используемые в ограниченном контексте, могут быть очень короткими. Традиционно имена i и j используются для обозначения счетчиков, р и q для указателей, s s для строковых, а сh для литерных переменных. В данном случае ясность достигается краткостью.
* Длинные имена могут быть сокращены. Следует придерживаться либо удаления несущественных суффиксов, либо удаления всех гласных букв кроме начальной, либо использования нескольких первых букв слова.
* Имена функций должны быть активными, т. е. базироваться на активном глаголе, за которым следует существительное.
* Имена перечислимых типов могут иметь единый префикс.
Приведем рекомендации по употреблению комментариев.
* Блочные комментарии следует применять для описания дополнительной информации о файле, классе, функции или переменной.
* Строковые комментарии следует использовать для коротких заметок в одну-две строки.
Языковые детали
Рекомендации по выравниванию.
* Стандартная величина отступа равна четырем пробелам.
* Табуляционный отступ равен восьми пробелам.
Об отступах
Величина отступа сильно зависит от языка программирования/ Существуют языки программирования в которых вложенность блоков определяется отступом (например, Occam или Руthon). Со стандартным отступом такие программы становятся просто неправильными
Рекомендации по написанию выражений.
* Бинарные операторы должны быть Отделены от операндов одним белом.
* Унарные операторы не следует отделять от операнда пробелом, ТОЛЬКО ЭТОГО не требуют правила языка.
* Используйте скобки, чтобы улучшить читаемость. Не следует добавлять пробелы к введенным скобкам.
* Старайтесь размещать выражение на одной строке.
* Если выражение переносится на следующую строку, то знак бинарной операции следует оставить на первой строке.
Рекомендации по объявлению переменных.
* В каждом объявлении должна объявляться только одна переменная.
* Объявление переменной ДОЛЖНО занимать одну строку.
* За типом переменной должны следовать пробел, имя переменной и комментарий с кратким описанием переменной.
* Если переменная является указателем, то символ * следует присоединять к типу.
Рекомендации по написанию Определения функций.
* Определение должно начинаться заголовком функции, за которым комментарий, описывающий назначение функции, и собственно функции.
* Открывающая и закрывающая фигурные скобки, определяющие функции, располагаются в первом столбце строк.
* Заголовок состоит из типа возвращаемого функцией значения, пробе имени функции, за которым без пробела следует открывающая круга скобка для списка параметров.
* Если функция статическая, то ключевое слово static должно быть вынесено в строку, предшествующую заголовку функции.
* Определение функции всегда начинается в самом левом столбце файла,
* Различные части функции следует отделять пустой строкой.
Рекомендации по написанию условного оператора.
* По одному пробелу следует оставлять перед и после круглых скобок условия.
* Открывающая фигурная скобка должна находиться на той же строке, что н закрывающая круглая.
* Закрывающая фигурная скобка находится на том же уровне отступа, что и начало условного оператора.
* Если условие не помещается на одной строке, то его продолжение на следующей строке должно начинаться в том же столбце, что и первый символ выражения первой строки.
* Если часть then или е1se состоит из простого оператора, то открывающая и закрывающая фигурные скобки могут быть опущены.
Пример форматирования условного оператора приведен в листинге 3.1.
Листинг 3.1. Пример форматирования условного оператора
if (********) {
=========;
}
else if (+++++++) {
---------------;
}
else {
_________ ;
}
Рекомендации по написанию оператора выбора: основные соглашения в этом случае выглядят так же, как и для условного оператора. Пример выравнивания оператора выбора приведен в листинге 3.2.
Листинг 3 2 Пример форматирования оператора выбора
switch ( i) {
case 1;
**********;
break;
сазе 2: {
+++++++++;
break;
}
__________;
break;
}
Рекомендации по написанию операторов цикла: в основных соглашениях следует опять ориентироваться на условный оператор.
Типичные примеры форматирования оператора цикла
Листинг З З Пример форматирования оператора цикла
for ( i = ************;
i> = --------------;
i = 0000000000) {
99999999999999999;
88888888888888888;
}
do {
99999999999999999;
88888888888888888;
} while (????????????) ;