$ git init myproject
$ cd myproject
$ ...
$ ./profit

Thinking of a name, making the directory, putting it under revision control, firing up your editor -- all this is easy. Imagining the endgame where your users get to use the result of all your work is a little harder. What's really hard is all that ... in the middle. Deciding what bits of your project go where can be a toughie though, unless you're lucky enough to already know where things ought to go, it can be a bit of a nightmare.

Fortunately for most generalised kinds of projects there will be one or more recommended layouts for your codebase, just like there's a standard for the over-all filesystem heirarchy. Let's explore a few of these...

Generic C/C++ project

Typically a generic C/C++ project will have a hierarchy akin to:

myproject/
  Makefile / configure.ac / CMakeLists / Whatever
  src/
    your C and C++ files go here, and headers private to the program
  lib/
    C and C++ files, for libmyproject go here
  include/
    header files for libmyproject go here

This isn't strict, and more complex projects will usually deviate in interesting ways from this, but it's a good start for a basic project.

Python Modules and programs

Python modules and programs often have a standardised shape too, in part because of the utilities which exist for preparing them:

myproject/
  setup.py
  myprojectlib/
    all your shiny library files in here, __init__.py etc.
  myproject

Again, while not strict, the python distutils define a number of expectations which when met make life easier for the budding pythonista.

Java

There are a number of 'standard' build systems for Java, but I'll show you the layout I've learned which seems to be common for gradle built apps of the kind I've played with, with IntelliJ IDEA as the IDE.

myproject/
  build.gradle settings.gradle gradlew etc. (gradle stuff)
  gradle/
    in here goes some magic to make gradle work
  myproject.ipr etc (IntelliJ stuff)
  src/
    main/
      java/
        myproject/
          Your java files go here
      resources/
        Your resources go here

Conclusions

Clearly the above do not encompass every kind of project, nor do they accurately represent all instances of the generalised kinds of project they claim to be; however they are good starting points if you are beginning a project and you're not sure quite how to lay it out. In a lot of cases, the general layout is dictated by the standardised tools for building such projects, and in that case it would behoove you to follow the standard for such tools as you choose to use.

Of course, which build tools you choose is another aesthetic (and functional) decision, and we'll perhaps cover that in a future article.

Ultimately what matters is that, for your project, your layout is logical and does not introduce difficulty when locating parts of the source. If necessary you can have a document in your source tree explaining where things are. So long as you stick to your layout consistently, noone will be overly upset if things are not quite as they expected.

---

P.S. I tried to include Go here, but it just made me feel sick so I gave up, sorry.

P.P.S. No, I never claimed to be non-partisan here.