Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm in the process of proposing a new standard directory layout that will be used across all the projects in our organization. Projects can have compiled source code, setup scripts, build scripts, third-party libraries, database scripts, resources, web services, web sites, etc.

This is partly inspired by discovering Maven's standard layout.

Are there any other standard layouts that are generally accepted in the industry?

share|improve this question
Could you be more specific about what you don't like in the Maven style and why? –  Péter Török Feb 4 '11 at 21:19
Very platform/language dependent. –  Mchl Feb 4 '11 at 21:20
Very related question: programmers.stackexchange.com/questions/40394/… –  Ryan Hayes Feb 4 '11 at 21:41
@Ryan Hayes I've edited my question to clarify that I mean more than just how to organize the compiled code, but all the artifacts that make up a project. –  splattered bits Feb 4 '11 at 22:24

2 Answers 2

For .NET, there's an app called Tree Surgeon that lays out a dev tree for .NET projects. It's kinda dated and I'm not sure how much of a standard it is, but it's an interesting starting point.

For my own projects outside of .NET, I tend to set up a folder for source, a folder for tests, and a folder for third-party libs that I depend on. There are often subfolders under each to allow for grouping by feature or namespace.

In .NET, I allow Visual Studio to organize itself and create a folder for the solution and then a folder per project under it, although I sometimes corral test projects into a "Tests" subfolder. I still create the "lib" folder for third-party dependencies and it typically goes under the main solution folder.

For web projects you can also look at frameworks such as Rails, Django, etc.

In general, when you consider the source layout, make sure you're not going to end up fighting the tools you use in order to maintain it. Some frameworks enforce layouts (Maven, Rails, etc.) and you can't do much about that. In some cases going against the flow would be merely an annoyance (as in Visual Studio), but it'd be a persistent annoyance that you'd have to deal with daily.

share|improve this answer

I generally look at it as there's two different things to consider here.

General Layout

This tends to be the high level folder structure that can some degree be influenced by your source control provider. Typically it will be something along the lines of

  • Project
    -- Branches
    -- Main
    -- Releases

Main may be broken down into other general folders (source, docs, help, etc.) but that detail depends upon the company and what is maintained alongside the source code in the source control provider. For example the projects I've worked where we used TFS the non-source artifacts (requirements, design, etc.) are stored in the associated SharePoint site. Most projects that I have worked on for the last 8 years have had a CMS (like) site of some kind to store and track the non-source artifacts.

Source Code

Like Anna Lear mentioned don't fight the tools. Most of us use IDEs which provide some level of 'natural' code layout for you. In my experience typically the biggest choice (naturally provided) is whether you stick your unit tests in a completely separate folder from the production code or intermingle it. A secondary consideration is that there is a limit to how long a path can be and if you nest too deeply you'll start to run into problems with compilation (maybe a bigger issue with windows than *nix, haven't worked on *nix in a while). Note that with the convention (.NET at least) of your folders creating your namespace structure in a project this can grow rather quickly if you don't keep an eye on it. I would like to think that many/most companies have standardized on how the source for any language/technology will be laid out, but I haven't seen it yet.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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