ansaurus

Question

What Is Your Software Development Directory Structure?

Answer 1

+4 A:

I'm a big fan of your more granular leaves, but at the top level I perform much better having the filesystem organized by project. I'm much more likely to be in a code directory and think, "Hey, what was the spec for this?" than be in the spec directory and think, "Which project did I want the spec for?" To rearrange your diagram:

|
|___webs____
|           |
|           |_blog.com_
|           |          |
|           |          |_docs_
|           |          |      |
|           |          |      |_mockups
|           |          |      |_user stories
|           |          |      |_...
|           |          |
|           |          |_code_
|           |          |      |
|           |          |      |_dev_
|           |          |      |     |
|           |          |      |     |_app
|           |          |      |     |_cfg
|           |          |      |     |_...
|           |          |      |
|           |          |      |_prod_ 
|           |          |      |_qa_
|           |          |      |_uat_
|           |
|           |_blah.com_
|           |          |
|           |          |_...
|
|_desktop___
|           |
|           |_noteapp__
|           |          |
|           |          |_...
|           |_...


                                                KEY
                                                dev  - development
                                                prod - production
                                                qe   - quality engineering
                                                uat  - user acceptance testing

That said, the organization at my office follows your methods, and seems to support a largish development environment. Personally, I find it really frustrating to have to search for mockups and other cases in directories other than the one my project is in (specifically, as an analyst, having specs separate from Marketing models, but I digress), but from a process-delegation standpoint separating these concepts probably makes a good deal of sense.

Just my two cents.

kyle 2009-01-14 06:15:25

I usually go with something like this as well; this way, old/dead projects don't get in my way and are clearly separated off in their own "namespaces"...

Reuben 2009-01-14 06:55:07

Answer 2

+3 A:

I store everything in a "c:\projects" directory on my windows machine and ~/projects on our unix-oid (linux & solaris) environments. Below that I have a "learning" (for code experiments and snippets /directory) and then one directory for each project. After some time, when a project is defunct, I erase the local storage and the code is archived only in SVN.

lexu 2009-01-14 06:18:38

Answer 3

+5 A:

I do the following:

Projects
- Project 1
  - Design
  - Docs
  - Code
- Project n
  - Design
  - Docs
  - Code
- Not active
  - Project 1
    - Design
    - Docs
    - Code
  - Project n
    - Design
    - Docs
    - Code

For some reason it helps me a lot to keep all the files grouped up by project, and keep my inactive projects (the ones I'm not currently working on) on a further down folder. I guess I get distracted by them otherwise.

Dave 2009-01-14 06:21:13

+1: I use the same structure (after extensive experimentation)

Stefano Borini 2009-07-24 00:00:27

What guidelines do you use to determine what you put in the Design folder versus the Docs folder?

Matthew Rankin 2009-12-25 04:40:14

Well, I try to collect every design aspect of the project on the "desgin" folder, for example, Photoshop layouts, logos, images, etc.As for the "docs" folder, I store everything related to documentation or client created documents in there.

Dave 2009-12-28 02:17:59

Answer 4

A:

I tend to prefer flatter directory structure and would like to recommend keeping it as simple as possible. Remember that, at least in Windowsland, there is a limit on command line length. Thus having very deep structures might spawn some nasty build errors.

Ignas Limanauskas 2009-01-14 06:56:45

Answer 5

A:

I just use a shorthanded name for each project and toss all relevant files and directories into that one directory. Something like this:

project_name (Project Name, "shorthanded")
- dir1/ (Not named like this in reality.)
- dir2/
- dirN/
- file1
- file2
- file3
- fileN

hydrapheetz 2009-01-14 06:56:52

Answer 6

A:

Files in svn:

SomeLibraryX
  SomeLibraryX.sln
  SomeFunctionA.cs
  SomeFunctionB.cs
  ..

SomeApplicationY
  SomeApplicationY.sln
  SomeApplicationY.cs          <-- might use SomeLibraryX as one of the dependencies

SomeApplicationZ
..

Files in some shared \\intra-pc\Releases\

SomeApplicationY 1         <-- folder used to execute compiled binary. Contains all the necessary input files needed for execution.
  Model                    <-- all input files like xml:s and 3ds:s 
  Textures                 <-- all pictures 
  Depencies                <-- all dependency executables and dlls
  SomeApplicationY.exe     <-- main exe
  SomeApplicationY.ini     <-- execution parameters file, that can be drag&dropped onto main exe

SomeApplicationY 2
  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationY 3            <-- the last demo-release of this project that is currently under construction (used for executing and debugging the exe)

  Model 
  Textures
  Depencies
  SomeApplicationY.exe
  SomeApplicationY.ini

SomeApplicationZ 1
...

AareP 2009-04-19 16:15:58

Answer 7

+1 A:

src\ <- Source codes for multiple projects (below)
tests\
- test_a <- module test for a for r&d (uses some of codes from src folder)
- test_b <- module test for b for r&d (uses some of codes from src folder)
- ...
main_app_folder <- Main project file for production (uses most of codes from src folder)
doc\ <- Documents
tools\
- tool_a <- tool a (uses some of codes from src folder)
- tool_b <- tool b (uses some of codes from src folder)
cleanup.exe / .ini <- utility for cleaning up temporary build files.

Project (in main_app_folder, tests or tools) can be .vcproj (visual studio c/c++), .mmp (Symbian makefile), Makefile (linux makefile). Each project has it's own main .cpp file - always containing a minimal set of functionality, everything else tends to be more or less reusable (in src\ folder).

Difference between test application and tool application is that tool display something more or less useful, while test only checks whether it works or not.

Difference between test and main application is that test application does not contain whole functionality, also test application might enable some special #define's needed for testing. Normally testing application is reduced set of main application without extra #define.

2009-04-21 07:28:34

Answer 8

A:

I usually use this directory structure:

proj_name
- code
  - src
  - test
  - build
- design
- doc
- tools

alem0lars 2010-10-09 17:01:46

ansaurus

tags:

views:

answers:

What Is Your Software Development Directory Structure?

related questions