There is a C language project, with more or less common structure, many source and header files (some divided in modules, some not), obviously not perfectly organized project, but still that is not a main issue.

The main thing is that all those header files in the project are included in one top header file, and then all other source files in the project are including this one top header file.

So if this would be the project structure:

.
├── C_Project
│        ├── top.h
│    ├── top.c
│        │
│        ├── file_1.h
│    ├── file_1.c
│        ├── file_2.h
│    ├── file_2.c
.        .
│        ├── file_X.h
│    ├── file_X.c
│        │
│        ├── module_1
│        │     ├── module_1.h
│        │     └── module_1.c
│        ├── module_2
│        │     ├── module_2.h
│        │     └── module_2.c
.        .
│        └── module_Y
│              ├── module_Y.h
│              └── module_Y.c

Here the situation is like this:

• top.h file is including all source file from the whole project: file_1.h, file_2.h, .., file_X.h, module_1.h, module_2.h, .., module_Y.h
• Then all source files (top.c, file_1.c, file_2.c, .., file_X.c, module_1.c, module_2.c, ..,module_Y.c) are including top.h file.

From all given over the web and university knowledge, this approach is so uncommon and kind of I can see many obstacles with this approach.

Also top.h is including many libraries (like string.h, math.h, etc.) which some of source files are consuming.

Somehow all this I see is so much in contrast with all good practices and advises given for C/C++ languages.

So in normal projects:

• Each source file is including its own header file (e.g. module_1.c would include module_1.h)
• Then (how you are going in the upper layers), source file that is consuming some other module will include its header file (e.g. top.c will include module_1.h, etc.).

And the question would be, do you see that this uncommon approach in this project has more benefits than disadvantages?

Can you list advantages vs disadvantages of this approach?