Need suggestions on organizing code files.

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.
Why 5 levels deep? Surely yuo should be putting common code in libraries that spread across, not deep.
Maybe an IDE could help you?
Actually the folder depth is deeper than 5.

And I'm not sure what you mean by common code?

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...


Last edited on
I currently use VS2008 professional edition.

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.
Last edited on
You should have something like:
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...


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?
Topic archived. No new replies allowed.