Code Organization
Author
Looking through various folders, I am finding code snippets and half done projects scattered across a bunch of different folders. I have a bunch of random stuff in my Visual Studio Projects Folder, and I have a couple of other folders that contain different programs or pieces of programs.
I'm curious as to how everyone keeps all of this organized? What conventions or methods do you use?
Mostly I just stick all of my stuff in subdirectories of a single directory. The names get pretty unimaginative though; test, test2, test3, test4, game1...game11 etc.
I have a main folder which contains all code, currently K:\Code In this folder I have one sub-folder for each solution, so for example I might have K:\Code\Miraoh1A if my solution is called Miraoh1A. On smaller project I tend to create a new folder for each project so we might have files like this:
K:\Code\Miraoh1A\M1ABase\Config.hpp
K:\Code\Miraoh1A\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\M1ABase\Convert.hpp
K:\Code\Miraoh1A\M1ABase\Convert.cpp
K:\Code\Miraoh1A\M1ABase\M1ABase.vcproj
K:\Code\Miraoh1A\M1AKernel\M1AKernel.hpp
K:\Code\Miraoh1A\M1AKernel\M1AKernel.cpp
K:\Code\Miraoh1A\M1AKernel\M1AKernel.vcproj
K:\Code\Miraoh1A\Miraoh1A.sln
With bigger projects I tend to split up files so that the file locations would look like this:
K:\Code\Miraoh1A\Include\M1ABase\Config.hpp
K:\Code\Miraoh1A\Include\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\Include\M1ABase\Convert.hpp
K:\Code\Miraoh1A\Include\M1AKernel\M1AKernel.hpp
K:\Code\Miraoh1A\Source\M1ABase\Convert.cpp
K:\Code\Miraoh1A\Source\M1AKernel\M1AKernel.cpp
K:\Code\Miraoh1A\Projects\M1ABase\M1ABase.vcproj
K:\Code\Miraoh1A\Projects\M1AKernel.vcproj
K:\Code\Miraoh1A\Projects\Miraoh1A.sln
This second approach can introduce some problems, but if I'm gonna create a big project anyway it doesn't matter. One thing I also do is having subfolders for each part of a project, even though all the files belong to a single .vcproj. So a project might look like this:
K:\Code\Miraoh1A\Include\M1ABase\Config.hpp
K:\Code\Miraoh1A\Include\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\Include\M1ABase\Convert.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\Log.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogManager.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogGroup.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogMacros.hpp
All these files would then belong to the M1ABase.vcproj file.
That is the way I organize my code files.
EDIT:
I also tend to use namespaces like the files is organized, so functions in convert.hpp would be in namespace Miraoh1A, while classes in LogManager would be in Miraoh1A::Logging because the file is in sub-folder Logging.
K:\Code\Miraoh1A\M1ABase\Config.hpp
K:\Code\Miraoh1A\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\M1ABase\Convert.hpp
K:\Code\Miraoh1A\M1ABase\Convert.cpp
K:\Code\Miraoh1A\M1ABase\M1ABase.vcproj
K:\Code\Miraoh1A\M1AKernel\M1AKernel.hpp
K:\Code\Miraoh1A\M1AKernel\M1AKernel.cpp
K:\Code\Miraoh1A\M1AKernel\M1AKernel.vcproj
K:\Code\Miraoh1A\Miraoh1A.sln
With bigger projects I tend to split up files so that the file locations would look like this:
K:\Code\Miraoh1A\Include\M1ABase\Config.hpp
K:\Code\Miraoh1A\Include\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\Include\M1ABase\Convert.hpp
K:\Code\Miraoh1A\Include\M1AKernel\M1AKernel.hpp
K:\Code\Miraoh1A\Source\M1ABase\Convert.cpp
K:\Code\Miraoh1A\Source\M1AKernel\M1AKernel.cpp
K:\Code\Miraoh1A\Projects\M1ABase\M1ABase.vcproj
K:\Code\Miraoh1A\Projects\M1AKernel.vcproj
K:\Code\Miraoh1A\Projects\Miraoh1A.sln
This second approach can introduce some problems, but if I'm gonna create a big project anyway it doesn't matter. One thing I also do is having subfolders for each part of a project, even though all the files belong to a single .vcproj. So a project might look like this:
K:\Code\Miraoh1A\Include\M1ABase\Config.hpp
K:\Code\Miraoh1A\Include\M1ABase\stdafx.hpp
K:\Code\Miraoh1A\Include\M1ABase\Convert.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\Log.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogManager.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogGroup.hpp
K:\Code\Miraoh1A\Include\M1ABase\Logging\LogMacros.hpp
All these files would then belong to the M1ABase.vcproj file.
That is the way I organize my code files.
EDIT:
I also tend to use namespaces like the files is organized, so functions in convert.hpp would be in namespace Miraoh1A, while classes in LogManager would be in Miraoh1A::Logging because the file is in sub-folder Logging.
The most important thing is to actually pay attention.
Once you find that the organization is less to your liking, spend the time to re-organize your files so they're more to your liking, and make sure everything builds/runs before you continue on other things.
Repeat the process over time. You gotta stay with it! Incrementally, you'll arrive at an organization that works well for your own needs.
Once you find that the organization is less to your liking, spend the time to re-organize your files so they're more to your liking, and make sure everything builds/runs before you continue on other things.
Repeat the process over time. You gotta stay with it! Incrementally, you'll arrive at an organization that works well for your own needs.
In a large-ish partition on my second hard drive, I have a folder named "Projects". Every PC-based project I ever work on goes in there, in a subfolder by name. (Naming the project is one of the first things I do, therefore. Sometimes I end up changing them, though.) Each project's folder contains subfolders based on the nature of the content -- Source, Debug, Release, Content, Docs, Design, etc. The Debug and Release folders contain, where applicable, binaries to run the program; the rest of the folders are subclassified yet again where necessary by subsystem (for example, Base, Renderer, ResourceIO, Net).
It seems to work fairly well.
Cheers,
Twilight Dragon
It seems to work fairly well.
Cheers,
Twilight Dragon
The first thing I do is make some high level project directories. For example, 'work', 'school' and 'personal'. Some of these might be divided further, IE 'school/Fall 2004', 'school/Spring 2005', etc. These may not apply directly to you, but I'm sure you can come up with something that works for you. Perhaps 'games', 'tools', 'tests'.
Second, I'm also guilty of test1, test2... on occasion. Try to be more descriptive than that, say 'qsort test' or 'AABB test'. Better yet, put it in the 'tests' directory as 'qsort' or 'AABB'.
Thirdly. Every so often I'll go through my projects and merge usefull code into a new project if its related stuff. If its throw away code, maybe I'll delete the project altogether. More likely I'll delete the debug and release folders to trim the size down and put it in a special directory, just on the off chance that I need access to something I thought was worthless one day. This could also be a .zip or .rar archive to save a little more space since text compresses pretty nicely.
Another tip is to merge common and usefull code into a personal library. Its a little wierd to set up the first time, but its so nice once you've got it. Before my current library was "libraritized" I was copying its project files into each new project that used it. Now I just include the lib file and set the include path. It also cleans up my doxygen-generated documentation since it seperates the library docs and project docs. It also generally shortens compile time a little.
Second, I'm also guilty of test1, test2... on occasion. Try to be more descriptive than that, say 'qsort test' or 'AABB test'. Better yet, put it in the 'tests' directory as 'qsort' or 'AABB'.
Thirdly. Every so often I'll go through my projects and merge usefull code into a new project if its related stuff. If its throw away code, maybe I'll delete the project altogether. More likely I'll delete the debug and release folders to trim the size down and put it in a special directory, just on the off chance that I need access to something I thought was worthless one day. This could also be a .zip or .rar archive to save a little more space since text compresses pretty nicely.
Another tip is to merge common and usefull code into a personal library. Its a little wierd to set up the first time, but its so nice once you've got it. Before my current library was "libraritized" I was copying its project files into each new project that used it. Now I just include the lib file and set the include path. It also cleans up my doxygen-generated documentation since it seperates the library docs and project docs. It also generally shortens compile time a little.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement