How to properly organize the code of a large project in C ++ (and not only)?

Question

Programming

Sooner or later, we all cross the line when writing helloworlds becomes boring and you want to create something big and cool. But so that the project does not turn into a big stinking pile of code, you need to competently approach its organization.
I would like to hear opinions on how you organize the code of your projects (preferably C ++). This is not only about the layout of the code into directories and the names of variables, but also about the architecture in general.
For example, I see for myself the following option.
Briefly about the style code (in principle, you can not read, there are thousands of them, I just like this one):

spoiler

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

File structure:
Example:

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 files contain the traditional crutch in the form of , well, or . First comes the inclusion of C++ headers, then third-party libraries such as boost, then the *.i file from this directory, and then everything else. Entities in each directory have their own namespace of the same name, i.e. , etc. *.i files contain: 1 forward declarations (so as not to pollute other files with them) 2 includes all *.h files from this directory. A controversial point, because. with small changes in the code, you will need to recompile a lot, but it is very convenient to include the required package (in terms of modern PLs) by including the *.i file. Ideally, all this should be automated and hidden behind syntactic sugar like#ifndef FILE_H#pragma onceengine::Coreengine::math::Vector3D

@import engine 
@from engine::math import *

Criticize my choice. I will also be glad to read examples of code organization in your projects. Thank you.

Answer 1

Capitalized class names in CamelCase, such as class EventHandler;.

Adopted in Java, Qt.
Adopted in Java, Qt.
Think whatever you want, but I don't think it's necessary.
Adopted in Java, Qt.
With so many files (and even five times more) - the norm.
Own header → standard C/C++ libraries → third-party libraries, and the more we architecturally depend on them, the earlier they are → internal files (again, the engine is earlier than utilities and data sets).
Your first header is paramount. As a rule, modules come in a header + compilation unit pair, and we immediately make sure that the header has all the necessary #includes.
Forward declarations specifically what?
The point is controversial, not even because of recompilation, but because of 1) cyclic dependencies between modules; 2) if you do it in the header, it can lead to a non-compiled project.
Namespaces should be much smaller than files, plus they should be as short as possible. Avoid using namespace.
Besides…
1) I recommend putting the main directory of the project into the header search directories. An #include should never have "directory up" ( ..).
2) Perhaps other people's libraries should be taken out of the project directory. Their directories are also in the header search directories.
3) It is strictly forbidden to repeat files in different directories.