Как правильно организовать код большого проекта на C++(и не только)? Все мы рано или поздно переходим тот рубеж, когда писать хелловорлды становится скучно и хочется создавать что-нибудь большое и крутое. Но чтоб проект не превратился в большую воняющую кучу кода, нужно грамотно подходить к его организации.
Хотелось бы услышать мнения на счёт того, как вы организуете код своих проектов(желательно C++). Речь не только про раскладывание кода по директориям и названия переменных, но и про архитектуру в общем.
Я, например, вижу для себя следующий вариант.
Кратко про код стайл(в принципе можете не читать, их тыщи, этот просто нравится мне): spoilerИмена классов с большой буквы в CamelCase, например class EventHandler;.
Названия объектов аналогично, но первая буква маленькая, например Image backgroundImage;.
Названия примитивных типов(int, char, double, etc) маленькими через нижнее подчёркивание, например double percent_of_fails;
Названия методов с мальнькой в camelCase и отражают действие функции, например void addModule(std::shared_ptr 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 *
Покритикуйте мой вариант. Также буду рад почитать примеры организации кода в ваших проектах. Спасибо.
Как правильно организовать код большого проекта на C++(и не только)? Все мы рано или поздно переходим тот рубеж, когда писать хелловорлды становится скучно и хочется создавать что-нибудь большое и крутое. Но чтоб проект не превратился в большую воняющую кучу кода, нужно грамотно подходить к его организации.
Хотелось бы услышать мнения на счёт того, как вы организуете код своих проектов(желательно C++). Речь не только про раскладывание кода по директориям и названия переменных, но и про архитектуру в общем.
Я, например, вижу для себя следующий вариант.
Кратко про код стайл(в принципе можете не читать, их тыщи, этот просто нравится мне): spoilerИмена классов с большой буквы в CamelCase, например class EventHandler;.
Названия объектов аналогично, но первая буква маленькая, например Image backgroundImage;.
Названия примитивных типов(int, char, double, etc) маленькими через нижнее подчёркивание, например double percent_of_fails;
Названия методов с мальнькой в camelCase и отражают действие функции, например void addModule(std::shared_ptr 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 *
Покритикуйте мой вариант. Также буду рад почитать примеры организации кода в ваших проектах. Спасибо.
Хотелось бы услышать мнения на счёт того, как вы организуете код своих проектов(желательно C++). Речь не только про раскладывание кода по директориям и названия переменных, но и про архитектуру в общем.
Я, например, вижу для себя следующий вариант.
Кратко про код стайл(в принципе можете не читать, их тыщи, этот просто нравится мне): spoilerИмена классов с большой буквы в CamelCase, например class EventHandler;.
Названия объектов аналогично, но первая буква маленькая, например Image backgroundImage;.
Названия примитивных типов(int, char, double, etc) маленькими через нижнее подчёркивание, например double percent_of_fails;
Названия методов с мальнькой в camelCase и отражают действие функции, например void addModule(std::shared_ptr 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 *
Покритикуйте мой вариант. Также буду рад почитать примеры организации кода в ваших проектах. Спасибо.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Ваш подход к организации кода в проекте на C++ выглядит довольно структурированным и грамотным. Разделение кода на модули и использование пространств имён помогает избежать конфликтов и делает код более читаемым. Также хорошо, что вы обращаете внимание на именование переменных, классов и методов, это тоже очень важный аспект организации кода.
Относительно использования *.i файлов для инклудов, это действительно спорный момент, так как это может привести к избыточной перекомпиляции кода при небольших изменениях. В идеале, конечно, такой процесс нужно автоматизировать, как вы сказали, чтобы упростить работу с подключаемыми пакетами.
В целом, ваш подход к организации кода вполне разумный и эффективный. Каждый разработчик имеет свой подход к структурированию кода, и важно найти тот, который наиболее удобен и понятен для вас. Если ваш метод работает и помогает вам эффективно разрабатывать проекты, то вполне возможно, что его стоит продолжать использовать.
Если вы хотите узнать другие методики организации кода в C++ проектах, рекомендую ознакомиться с практиками разработки ведущих программистов и команд, таких как Google C++ Style Guide, ISO C++ Core Guidelines и др. Там можно найти много полезных рекомендаций и советов по структурированию кода в C++.