devalone
@devalone
̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻̻

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

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

Хотелось бы услышать мнения на счёт того, как вы организуете код своих проектов(желательно 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 *


Покритикуйте мой вариант. Также буду рад почитать примеры организации кода в ваших проектах. Спасибо.
  • Вопрос задан
  • 2331 просмотр
Пригласить эксперта
Ответы на вопрос 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) Категорически запрещены повторы файлов в разных каталогах.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы