Sign in to follow this  
Dirge

File organization survey

Recommended Posts

Inquiring minds must know! How do you organize your source and header files? Include and Source directories? i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp OR Codebase/Foo.h, Codebase/Foo.cpp etc... OR Some other way? What are the merits of one over the other? How should nested hierarchies work when using an Include/Source directory structure (i.e. Codebase/Include/FooLib/Foo.h OR Codebase/FooLib/Include/Foo.h)? I know this is a silly question but please humor me. :-)

Share this post


Link to post
Share on other sites
My reply won't help you directly since it's not C++, but I think it's also interesting to see how people organize in general - there is a lot more apart from code after all. You did say "survey", so that's my excuse for this somewhat tangential reply :)


In SVN, my structure looks like:

some-project
some-other-project
|
|-tags
|-branches
|-trunk
|
|-(same as on disk, except for temp data)

On disk, I have (for big project):

sol-engine-core - separate from game to prevent dependencies
|
|-bin/ - compiled class files from Eclipse (not in SVN)
| |-test/ - compiled unit test cases
| |-core/ - compiled class files for project
|
|-src/ - contains game-specific source code (package tree)
|-test/ - unit test cases source (package tree)

solariad - game files proper, set up, game logic, game loop
|
|-bin/ - same as above, not in SVN
|-content/ - first stage of asset pipeline, all raw assets are here
| |-art/
| |-audio/
| |-models/
|
|-data/ - contains all processed assets that are part of the game proper
|-dist/ - the redistributable "gold master", where everything comes together during the build process (Ant script) This is not in SVN
|-src/ - source package tree
|-web/ - everything related to solariad.com




Big disadvantage is that every processed asset is version-controlled twice, but I have more than enough disk space on my NAS so it hasn't been a problem yet. Asset pipeline in general is actually somewhat of a problem for me, but this is the "poor man's version" I came up with so far.

Share this post


Link to post
Share on other sites
One of the standard linux layouts is to have the structure:
code/include/*.h
code/src/*.cpp
this is good for compilation and library linking.
1) everything that needs to be is already sperated, you don't have to do any extra work to pull the cpp files out of the library.
2) everything else is already in one place, so your #includes can be shorter and you need less include directories to send to the compiler.

On the other hand, for smaller projects and subsystems I prefer the layout:
code/stuff/*.h,*.cpp
It means less jumping around the folder structure when I'm looking for things. But it does mean that folders have 2x the number of files. And you tend to have a lot of folders.

Another structure I'm quite partial to is:
code/*.h
code/platform_pc/*.cpp
it has some of the benifits of the first approach, with the locality of the second aproach.
Besides, I'd rather edit X files when an interfaces changes then have to look at code that is a jumble of #if _PLATFORM_X_ directives.

[Edited by - KulSeran on May 31, 2009 7:32:14 PM]

Share this post


Link to post
Share on other sites
Most of my projects are in C# so it's a little different, but for my projects I have folders for the different name spaces that I create and then all the source files for a name space go in that folder.

When I'm working with assets I tend to not keep them as organized as I should and have everything in the same Content folder. If I ever start work on a project big enough though I would probably have sub folders within the Content folder for UI, Models, Sound and anything else that the game would require.

Share this post


Link to post
Share on other sites
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.

Let me pose an additional question; How useful would it be to have a number of sub-directories as an additional organizational structure? In other words, if you were working on your graphics renderer and had a number of files related to models and textures (ex. not just model.cpp but model_loading.cpp, model_rendering.cpp, model_exporter.cpp, texture_loading.cpp etc...), does it make sense to have a denser hierarchy like:
Renderer/D3D/Include/Models/Model_Rendering.cpp, Renderer/Common/Include/Textures/Texture_Loading.cpp, ...

Share this post


Link to post
Share on other sites
Quote:
Original post by Dirge
Sorry, I shouldn't have narrowed it down to c/c++ codebases. This subject relates to large codebases of any language.


To an extent; but C and C++ have unique decisions to make because of the whole header vs. source file thing. :)

Share this post


Link to post
Share on other sites

<project-name>/
env/<compiler-version>/<compiler>.sln *
src/<project-name>/
src/ non-shared sources (usually .cpp & .hpp)
inc/ shared sources (usually .inl and no-extention)
env/<compiler-version>/ project specific data, usually just the .vcproj
bin/<config>/<project-name>/ tempory build data
dist/<config>/ distribution files, usually .dll and .exe

* vs2005.sln for visual studio 2005 (by naming the solution after the compiler-version I can use it as a readable variable - anyone got any other options I'm all ears)

The reason behind this is that some projects will have to be build with several compilers. There is one project at work that needs to be built for visual studio 6.0 to 2008, both 16, 32 and 64 bits where applicable(supporting legacy application is fun).

For .net I've found the default to be sensible enough :)

Share this post


Link to post
Share on other sites
Quote:
Original post by gekko
"Codebase/Foo.h, Codebase/Foo.cpp etc..."

That is the only one Visual Studio is friendly with, so it's the one I use.


Visual studio can cope with /include and /src directories. Just remember to add the include path to your include paths in the project settings and you should be all set.
When adding files, You just have to add the path, so rather than adding foo.cpp, add src/foo.cpp


Anyway, at present I stick with
src/*.cpp
include/*.h
test/*.cpp;*.h
obj/<build string>/*.o
bin/<build string>/*.*

No doubt, given a few more years of experimenting it will change *shrugs*

Share this post


Link to post
Share on other sites
Quote:
Original post by Dirge
Include and Source directories?
i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp
We used to do exactly that, until we realised how awful it was.
The context menu item in VS "Go to header" doesn't work unless they are in the same dir.
What's more, adding both the source file and the header to a project requires browsing for files to add twice, rather than a multi-select in one directory.

Keep them in the same dir.

Share this post


Link to post
Share on other sites
If you plan to use SVN, use it WISELY or don't use it at all. It can make your files disappear in an eye blink, and is rather inflexible at some points (renaming files etc, or moving files).

I lost half a project because of it, no more version controlling system for me.

Share this post


Link to post
Share on other sites
Quote:
Original post by Decrius
If you plan to use SVN, use it WISELY or don't use it at all. It can make your files disappear in an eye blink, and is rather inflexible at some points (renaming files etc, or moving files).

I lost half a project because of it, no more version controlling system for me.


Huh? What did you do? That's some pretty bad luck. I move around, rename and delete files (both inside the SVN and on the local drive through the IDE) all the time; haven't had any problems yet.

Share this post


Link to post
Share on other sites
Quote:

If you plan to use SVN, use it WISELY or don't use it at all. It can make your files disappear in an eye blink, and is rather inflexible at some points (renaming files etc, or moving files).

I lost half a project because of it, no more version controlling system for me.


That sounds like really bad user error. Version control is a must though. Even for your own small projects. I've lost more code due to NOT having version control than I ever have by using version control.

Share this post


Link to post
Share on other sites
This is the general pattern of what I'm using now.

/libraries/include/library1/*.h
/libraries/include/platform-specific/*.h
/libraries/src/library1/*.cpp
/libraries/src/library1/platform-specific/*.cpp
/app/*.h,*.cpp

Projects add /libraries/include and /libraries/include/platform-specific (for their platform) to their search paths.

Includes look like this:
#include "library1/someheader.h"


Share this post


Link to post
Share on other sites
Quote:
Original post by iMalc
Quote:
Original post by Dirge
Include and Source directories?
i.e. Codebase/Include/Foo.h, Codebase/Source/Foo.cpp
We used to do exactly that, until we realised how awful it was.
The context menu item in VS "Go to header" doesn't work unless they are in the same dir.
What's more, adding both the source file and the header to a project requires browsing for files to add twice, rather than a multi-select in one directory.

Keep them in the same dir.


It's extra cash per developer, but Visual Assist X handles this case fine, and does some excellent basic C++ refactoring. I miss it whenever I use a different IDE.

Share this post


Link to post
Share on other sites
i like to have all files together for small projects:

Project/*.cpp *.h



I use a makefile that scans for all cpp files anf compiles all of them and then links them.

for bigger projects i use a folder hierarchy:

Project/
Part1/*.cpp *.h
Part2/*.cpp *.h



I do all my coding in linux and mostly cpp.
I have used the same strategy for java and some assembly files.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this