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.

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.
If this question can be reworded to fit the rules in the help center, please edit the question.

2

Could you be more specific about what you don't like in the Maven style and why?
–
Péter TörökFeb 4 '11 at 21:19

4 Answers
4

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.

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.

That project structure is kind of forced by subversion due to limitations in that tool. I would not describe it as a good thing.
–
PtolemyMay 27 at 7:14

@Ptolemy there's no reason svn uses those 3 except that its a convention that reflects the 3 areas people store stuff in their SCMs, regardless of tooling. Microsoft calls them Main, Dev and Release in their docs, but they're the same thing. git uses master, develop and release ... I think Ken just got directory layout and SCM branches confused in his answer.
–
gbjbaanbMay 27 at 7:26

git, hg, CVS and even Team Foundation server implement branches independently of directory structure. SubVersion implements tags, and branches as part of the directory structure. It kind of works, but I would not work with branches in Subversion as care free as I do in git.
–
PtolemyMay 27 at 7:31

As your question points out, project structures are often the result of the build toolset, and how the developers tools is designed to manage and organise code. Maven has a strict layout, which enables it to provide a very structured build process. Visual Studio imposes a directory structure for within MVC web projects. Erlang/OTP/rebar creates a very structured way in which projects are laid out.

Think about the tools you are using and if they imposer constraints on you, and then the needs of the humans on the project to classify and understand the project structure.

Finally, as its a standard it needs to be documented clearly, and most importantly, made easy for your fellow workers to implement.