Structuring your source code

05.09.2009 16:10Comments
Probably one of the first things I do when I start up a project is to get my repository and build up my basic structure. It seems easier than it actually is to do this, and I've seen a lot of different ways to do this, most of them being valid. So here I show you how I structure my projects: Project Basic Structure I usually use SVN because it makes working offline very easy. If I were to work on a centralized team (all the members in one office), and I were to have the option of using TFS, I would go for TFS in that case, but not because I consider it's a better source control solution, but because it makes it easier to integrate the code with all the other features that come with VS Team Edition. I will briefly explain each of the folder's purpose.
  • Doc: self-explanatory, contains projects documents. The very least this folder should have are: Project Overview document and Architecture document.
  • branches: I use this folder for temporary, or experimental work on the product. An example of temporary work could be a parallel work, or enhancement that want to merge to the trunk later. Experimental work could be to try a new feature or framework to see how it works, and then disregard this branch for the rest of the project.
  • tags: this is actually much more important than it seems (maybe the most important of them all). I wouldn't even think of making a deployment without tagging the version I am dropping. This is where you will go to retrieve your code whenever a critical bug appears on production.
  • trunk: finally, the one we all know, the actual trunk of the source code. Here is where all of you source code will rest. This is where we work most of the time, and where we commit the incremental changes.
  • db: as you can see, this folder is INSIDE the trunk, and suggests that it's where the database is. That's right, versioning the database is as important as versioning the code itself (more on this on post). Why am I choosing this place for the database? Because when we tag a version (due to a deployment for instance), we need that tag to contain the database. So by tagging the trunk, you will have everything you need to reproduce that version's environment.
  • lib: sometimes we need libraries for our projects, and many times we need to change the code of those libraries. Here is where those projects will rest. Another interesting example of what we could put in here are libraries which we use to either build or test our project, such as Nant and Nunit. The reason for putting these libraries here is so that everyone in the team tests, and builds with the same version.
  • src: nothing more, nothing less than the code itself. If this were a visual studio's solution, here would be the sln file ;)
  • this would be a visual studio project, and it doesn't have to be a module, could be anything, however, I would stick to the* naming convention.
  • srccompany.namemoduletests: again no need to be a module, however, for every "testable" project, I would put the unit tests in a separate project, following some kind of naming like the one here.
  • srcreferences: making reference to visual studio project's references, this folder contains all the external dlls for which the code is not in our solution.
If you have any suggestions, or improvements, I would like to here them, and even add them to this post! Gus

comments powered by Disqus