Reproducible Research › Module 2: Organising work
A project folder that explains itself
Lesson 1 of 3 · 2 min
A stranger should be able to open your project and understand it in two minutes. A consistent folder layout does most of the work.
A simple layout
| Folder or file | What goes in it |
|---|---|
| README.md | What this is, how to run it, who made it |
| data/raw/ | Original data, exactly as received |
| data/processed/ | Data your code produced |
| src/ or code/ | Scripts and functions |
| notebooks/ | Exploration |
| results/ | Figures and tables, all made by code |
| docs/ | Notes, the paper draft |
- README.md
- What goes in it: What this is, how to run it, who made it
- data/raw/
- What goes in it: Original data, exactly as received
- data/processed/
- What goes in it: Data your code produced
- src/ or code/
- What goes in it: Scripts and functions
- notebooks/
- What goes in it: Exploration
- results/
- What goes in it: Figures and tables, all made by code
- docs/
- What goes in it: Notes, the paper draft
This follows the advice in "Good enough practices in scientific computing" by Wilson and colleagues, and William Noble's guide to organising computational biology projects.
Rules that make it work
- One project, one folder. Everything needed lives inside it.
- Relative paths (data/raw/survey.csv), never paths like C:/Users/me/Desktop/final2.
- Results are disposable. Anything in results/ can be deleted and rebuilt by running the code.
- README first. Write it on day one, and update it as you go.
When it's too much
For a one-week assignment, a README, a data folder and a script are enough. The point is not the exact names; it's that the layout is predictable.
RememberOne folder per project, a README on day one, raw data separate, and every result rebuildable by code.