Coding Style. Part 1

»Стиль программирования. Часть 1«
Читать другие материалы серии статей "Стиль программирования":
Вступление, Часть 1, Часть 2

Общие рекомендации

Совет 1
Оптимизируй код, только если действительно уверен, что проблема заключается в производительности программы. Подумай дважды перед тем, как начнешь. Найди узкие места, и подумай снова. Ведь современные компиляторы C++ в плане оптимизации довольно хороши. А код, который, по-твоему, кажется быстрым, необязательно генерирует быстрый объектный код. Он только усложняет понимание и сопровождение.

Помни о следующем: "Преждевременная оптимизация — корень всех зол" (Дональд Кнут).

Совет 2
Перед тем, как закончить разработку программы, скомпилируй ее при помощи другого компилятора и на другой платформе. Если она была разработана при помощи MS Visual C++ под WinXP, скомпилируй и протестируй код при помощи компилятора GNU C++ на платформе Unix, и наоборот. Еще лучше попробовать скомпилировать каким-нибудь третьим компилятором. Возможно, обнаружатся едва уловимые ошибки и некоторые проблемы переносимости.

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

Структура исходного кода

Правило 2
Файлы заголовков (header files) в C++ всегда имеют файловое расширение ".h"

Правило 3
Файлы реализации (implementation files) в C++ всегда имеют файловое расширение ".cpp"

Именование файлов

Правило 4
Определяй имена файлов таким образом, чтобы они, по возможности, были уникальными в как можно большем контексте.

Файл заголовков для класса должен именоваться следующим образом: "<имя класса>.h". При этом используй прописные и строчные буквы так же, как и в исходном коде.

Так как имена классов уникальны в некотором большом контексте, это свойство отображается и на уникальность имен файлов.
Структура проекта

Правило 5
Каждый проект (библиотека или приложение) имеет свой собственный каталог с хорошо выстроенной структурой.

Каталог проекта содержит файлы настройки, make-файлы, а также каталоги для заголовочных файлов, файлов реализации, документацию и тестовый набор.

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

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

Правило 7
Все файлы реализации и неоткрытые заголовочные файлы размещаются в каталоге src.

Правило 8
Все файлы с настроками проекта, make-файлы и другие файлы, не содержащие исходный код, должны находится непосредественно в каталоге проекта (в корне).

Совет 4
Если проект содержит дополнительную проектную документацию (например, спецификацию или другие стандартные документы), они должны находится в каталоге doc.

Продолжение следует...
Чтобы быть в курсе последних статей, подпишись на RSS. Это просто!

Сергей | codeBlogZ