23

I have been experimenting with directory structures and am currently using the one below:

 |
 |_projects__
 |           |
 |           |_blog.com_
 |           |          |_mockups
 |           |          |_user stories
 |           |          |_....
 |           |
 |           |_noteapp__
 |                      |_mockups
 |                      |_....
 |
 |_webs______
 |           |
 |           |_dev______
 |           |          |_blog.com_
 |           |                     |_app
 |           |                     |_config
 |           |                     |_....
 |           |
 |           |_prod_____
 |           |          |_blog.com_
 |           |                     |_app
 |           |                     |_....
 |           |_qe_....
 |           |_uat_....
 |
 |
 |_desktops__
             |
             |_dev______
             |          |_noteapp_
             |                    |_app
             |                    |_config
             |                    |_....
             |
             |_prod...
             |_qe....
             |_uat....

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

Webs store web applications, desktops store desktop applications. The dev directory is version controlled, while the other directories (prod, qe, uat) store their respective current releases. The project directory stores non-code related project items.

What is your software development directory structure and is there a reason you recommend that structure?

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
Laz
  • 3,474
  • 9
  • 33
  • 46

9 Answers9

10

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.

David
  • 3,226
  • 3
  • 23
  • 18
  • 1
    +1: I use the same structure (after extensive experimentation) – Stefano Borini Jul 24 '09 at 00:00
  • What guidelines do you use to determine what you put in the Design folder versus the Docs folder? – Matthew Rankin Dec 25 '09 at 04:40
  • 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. – David Dec 28 '09 at 02:17
5

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
  • 1,460
  • 2
  • 15
  • 21
  • 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 Jan 14 '09 at 06:55
5

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
  • 8,766
  • 5
  • 45
  • 63
2

I usually use this directory structure:

  • proj_name
    • code
      • src
      • test
      • build
    • design
    • doc
    • tools
alem0lars
  • 660
  • 2
  • 10
  • 23
2

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

1

I tend to group all my projects into three main directories:

  • Webdesign => For anything web related;
  • Programming => For anything that isn't related with the web (even if it has network capabilities);
  • Research => For anything where I have to read papers in order to do it;

Then inside these folders I have:

  • Incubator => For new projects or for projects that I adopt;
  • Retirement (or atic) => For projects that are inactive;
  • n directories for each of my actively develop projects;

Also each project is maintained in a git repository, with a doap file describing it (along with the usual stuff, like README, INSTALL, NEWS, AUTHORS, LICENSE (usually apache2), an docs dir, and srcs dir and optionally an libs dir and a build file). If any projects are connected then the doap file says something about it (or I just create a folder for the root project and place all of the related projects in it). The only exception to these two paragraphs above, are some projects in the atic (some of then written in Delphi 2...).

Also, only sources are stored, since I can quickly create binaries out of them.

P.S.: If this reminds you of something you know, it's because I've inspired myself in apache software foundation to organize my projects, so I have the labs (or research), the atic, the incubator, the doap files, etc. Because I'm mostly a java man these days, and apache came to my mind...

Coyote21
  • 432
  • 5
  • 10
0

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
  • 2,436
  • 7
  • 28
  • 32
0

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
  • 3,540
  • 3
  • 17
  • 12
0

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
  • 2,355
  • 3
  • 21
  • 28