So I'm getting to a point in my project that the depth of the 'code' folder can go about 5+ folders deep... I tried to abate the complexity by creating files called dir.hpp that includes the .hpps files within the folder. Then having files that need those resources include "dir.hpp" rather than the individual header files.
So that if a file has changed name, or moved, I just have to edit the dir.hpp of each folder.
Are there better ways of organizing code files?
I'm primarily looking for ways of effectively organizing around ~500 header/source files.
The project is spread into branches of code, such as security, refactor, networking, gui, etc.
They are split off from the main body of code already existing in main. So lets say the main project consists of about 50 files, then security is built off of that and does not contain any duplicates of main.
Security itself contains several more branches, which (like security's relationship with main) does not duplicate any code.
It would look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Folder: Main
Folder: Security
Folder: security_utils
Folder: tools
Folder: unit tests
Folder: automation
Folder: security_client
Folder: binary checker
Folder: user binaries
Folder: user preferences
Folder: security_server
Folder: data validator
Folder: physics validator
Folder: user profile
....
...
Folder: GUI
Folder: Networking
Folder: etc...
I use the IDE extensively to visually separate the files but that does nothing for the physical location of each file. Having anything more than 100 files in 1 folder is a headache to deal with.
A significant number of files have exactly the same name as well.
Folder: Main
Folder: Security
Folder: security_utils
Folder: tools
Folder: unit tests
Folder: automation
Folder: security_client
Folder: binary checker
Folder: user binaries
Folder: user preferences
Folder: security_server
Folder: data validator
Folder: physics validator
Folder: user profile
....
...
Folder: GUI
Folder: Networking
Folder: etc...
Why? Because these components aren't really subordinate to Main. If you added another top level component that had GUI, Networking and Security requirements, you'd expect it to share what you already have. Some aspect of these components are almost surely suitable to be made into libraries.
I had kept them in a single folder for all the top level stuff. Well that's one level gone...
Well the current set up is, server compiles all the source every few hours, then releases the binaries, and I download the binaries along with whatever part of the source I'm working on that day. Then testing gets to it and has fun. I agree with you that some should just be made into libraries, but one of the source control's tests is to make sure all release binaries are up to date. Any binary falling behind is considered a build error and someone has to look into why a single binary is maybe 1 day out of sync with the rest.
Sounds like a headache but it's saved the day a few times, ever had a dev integrate their code building from old out of date binaries?