What are standard directory layouts for source code, other libraries, build scripts, etc.?

Question

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?

Answer 1

I am just starting in programing, but i have seen many project use this one:

• src: where you place your source code, generally in folders by hierarchy and the project own structure
• bin: where you can place the compiled files
• script: where you can place, scripts for the user
• test: where you can place scripts that test the program
• docs: where you should place documents explaining the project
• examples: where you should place examples of how to use the project
• dist: where you can place the uncompiled source code package
• build: where you can place the compiled distributions, generally in folders by platform
• you should also place your building/compiling/distribution script in the project root folder, along with files like copyrights and readmes

I found an Oracle document describing and standard layout for some project, you can see many similarities:

https://docs.oracle.com/cd/E17076_04/html/porting/layout.html

edit

It have also seen a lib folder, i imagine here you should place external libraries, i did not think of it because i use python where tools like pip automatically download and install them

Answer 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.

Answer 3

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.

Answer 4

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.