Как правильно организовать код большого проекта на C++(и не только)?

Question

[devalone]

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

Хотелось бы услышать мнения на счёт того, как вы организуете код своих проектов(желательно C++). Речь не только про раскладывание кода по директориям и названия переменных, но и про архитектуру в общем.

Я, например, вижу для себя следующий вариант.

Кратко про код стайл(в принципе можете не читать, их тыщи, этот просто нравится мне):

spoiler

Имена классов с большой буквы в CamelCase, например class EventHandler;.
Названия объектов аналогично, но первая буква маленькая, например Image backgroundImage;.
Названия примитивных типов(int, char, double, etc) маленькими через нижнее подчёркивание, например double percent_of_fails;
Названия методов с мальнькой в camelCase и отражают действие функции, например void addModule(std::shared_ptr<Module> module);

Структура файлов:
Пример:

engine/
|
|-engine.i
|-core.h
|-core.cpp
|-math/
  |
  |-math.i
  |-vector3d.h
  |-vector3d.cpp
|-scene/
  |-
  |-scene.i
  |-scene.h
  |-scene.cpp
  |-object.h
  |-object.cpp

*.h файлы содержат традиционный костыль в виде #ifndef FILE_H, ну или #pragma once. Первым идёт инклуд C++ хедеров, затем сторонние библиотеки типа буста, затем *.i файл из данной директории и после всё остальное. Сущности в каждой директории имеют своё одноимённое пространство имён, т.е. engine::Core, engine::math::Vector3D и т.д.
*.i файлы содержат:
1 forward declarations(чтоб не замусоривать ими остальные файлы)
2 инклуды всех *.h файлов из данной директории. Спорный пункт, т.к. при небольших изменениях кода нужно будет много перекомпилировать, но зато очень удобно подключать нужный пакет(если говорить в терминах современных ЯП) инклудом *.i файла.

В идеале это всё нужно автоматизировать и скрыть за синтаксическим сахаром вроде

@import engine 
@from engine::math import *

Покритикуйте мой вариант. Также буду рад почитать примеры организации кода в ваших проектах. Спасибо.

Comments

[Ярослав Иванов]

Как правильно организовать код большого проекта

Прочитать книгу "Совершенный код"

[Iron Bug]

Рекомендую книгу
www.ozon.ru/context/detail/id/2381848

Ну и исходники больших проектов.

Answer 1

[Mercury13]

Имена классов с большой буквы в CamelCase, например class EventHandler;.

Принято в Java, Qt.

Названия объектов аналогично, но первая буква маленькая, например Image backgroundImage;.

Принято в Java, Qt.

Названия примитивных типов(int, char, double, etc) маленькими через нижнее подчёркивание, например double percent_of_fails;

Думайте как хотите, но, по-моему, нет нужды.

Названия методов с мальнькой в camelCase и отражают действие функции, например void addModule(std::shared_ptr module);

Принято в Java, Qt.

Структура файлов:

При таком количестве файлов (и даже впятеро большем) — норма.

Первым идёт инклуд C++ хедеров, затем сторонние библиотеки типа буста, затем *.i файл из данной директории и после всё остальное.

Свой хедер → стандартные библиотеки Си/Си++ → сторонние библиотеки, причём чем больше мы от них архитектурно зависим, тем они раньше → внутренние файлы (опять-таки, движок раньше утилит и наборов данных).

Первым свой хедер — это архиважно. Как правило, модули идут парой «хедер + единица компиляции», и мы сразу же убеждаемся, что в хедере есть все нужные #include.

1 forward declarations(чтоб не замусоривать ими остальные файлы)

Forward declarations конкретно чего?

2 инклуды всех *.h файлов из данной директории.

Пункт спорный даже не из-за перекомпиляции, а из-за 1) циклической зависимости между модулями; 2) если сделать это в хедере — может привести к некомпилирующемуся проекту.

Сущности в каждой директории имеют своё одноимённое пространство имён,

Пространств имён должно быть намного меньше, чем файлов, плюс они должны быть предельно короткими. Избегать using namespace.

Кроме того…
1) Рекомендую в каталоги поиска хедеров поставить основной каталог проекта. В #include ни в конем случае не должно быть «каталог вверх» (..).
2) Возможно, чужие библиотеки стоит вынести из каталога проекта. Их каталоги также стоят в каталогах поиска хедеров.
3) Категорически запрещены повторы файлов в разных каталогах.

Comments

[devalone]

Forward declarations конкретно чего?

Классов из данного "пакета", т.е. из данной директории.

Пункт спорный даже не из-за перекомпиляции, а из-за 1) циклической зависимости между модулями

Разве? При инклуде *.i файлов проблем не возникает на простом примере:
a/
|
|-a.i
|-a.h
|-a.cpp
b/
|
|-b.i
|-b.h
|-b.cpp
Где A содержит указатель на B, а B содержит указатель на A.

Пространств имён должно быть намного меньше, чем файлов, плюс они должны быть предельно короткими. Избегать using namespace.

Ну их и будет меньше, один namespace на директорию)
Могут возникнуть какие-то проблемы, если сделать скрипт, который будет транслировать этот код:

@from engine::math import Vector3D

class Object
{
// ...
private:
    Vector3D position;
    Vector3D speed;
}

в следующий:

#include <engine/math/math.i>

class Object
{
// ...
private:
    engine::math::Vector3D position;
    engine::math::Vector3D speed;
}

?

[Mercury13]

devalone:

Где A содержит указатель на B, а B содержит указатель на A.

1. Циклическая зависимость — это когда модулю A нужно что-то из модуля Б, и наоборот. По интерфейсам строго недопустимо, по реализациям крайне не рекомендуется.
2. Не будет компилироваться, если #include "xxx.i" в хедере, и в i-файле окажется зависимый модуль (например, есть функция, которой нужен тип из нашего хедера).