0

This question already has an answer here:

I'm currently working on a C++ project in Visual Studio and can't make up my mind on how I should be organizing my files. As of currently, my file directory looks similar to the following.

->source
    -> game
        ->file1.cpp
        ->file1.h
        ->file2.cpp
        ->file2.h
        ->...
    -> libraries // usually reserved for external libs
        ->lib1
            ->file1.cpp
            ->file1.h
        ->lib1
            ->include // header files
            ->lib // compiled .libs & .dlls

->visual studio
    -> // visual studio project stuff

I will be the first to admit that I haven't put too much thought into how everything should be organized. My philosophy for the "source" folder is to contain any source code or compiled libraries that will be included in my Visual Studio project. However, I could see this folder getting messy after a while. I also know that some people separate header and source files into different directories, but this just seems like extra folder navigation without much benefit.

I'm curious if there are any standard methodologies for organizing Visual Studio projects. I would like to avoid the huge organization refactor later down the road.

marked as duplicate by Deduplicator, gnat, Bart van Ingen Schenau, gbjbaanb, BobDalgleish Aug 30 at 14:54

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • The project structure looks fine to me. The source folder will get "large", but not necessarily "messy". Regarding the issue of separating headers and source files, this is a popular approach used by open-source libraries, where public API headers are placed into their own directories, separate from source files and internal headers. If you do not intend to share your code, it is not necessary to keep a clear line between "public API" and "internals". (It might make sense to make this distinction, but only if your project gains traction and grows very big.) – rwong Aug 30 at 2:57
2

I generally try to separate out groups of files by related functionality. For a game, you're likely to have files related to various aspects of a game such as:

-> source
    -> game
        -> rendering
            -> renderer.cpp
            -> renderer.hpp
            -> material.cpp
            -> material.hpp
            -> mesh.cpp
            -> mesh.hpp
            ... etc.
        -> physics
            -> physics.cpp
            -> physics.hpp
            -> collisions.cpp
            -> collisions.hpp
            ... etc.
        -> entities
            ...
        -> audio
            ...
        -> networking
            ...
        ... whatever else

I find when first putting together a project, I don't know what the sub-categories will be. So I'll put everything under /game. Once I feel like I've got 2 or 3 files related to the same area, I'll move them into a new sub-folder for that topic. Sometimes I have to go back and rethink things, but that's not too often.

  • 1
    This is the organisation structure I use, but I err on the side of creating sub-categories - they're easier to remove than add IMO - and I also use sub-sub-categories. This is also how every professional game project I've worked on has been organised. – Jack Aidley Aug 30 at 11:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.