Setting Up a Research Project

The Plan

• The goal of project structure: every result in your paper is rebuilt by code you can rerun
• The self-contained folder, anchored by one .Rproj, that makes here() work
• Standard subfolders, and why raw data is read-only
• Two ways to start a project: by hand, or from a template

The Standard You’re Aiming For

• Every number, table, and figure in your paper is produced by code you can rerun
• No hand-copied numbers, no “I tweaked that in Excel,”
• If a reviewer asks where Table 3 came from, you can point at the exact script

One Folder, Self-Contained

• A project is a single folder that holds everything the analysis needs
• Code, data, output, and writing all live inside it
• Move the folder to another machine and it still runs — nothing points outside it

The Anchor: .Rproj

• One file at the top of the folder marks it as a project: project.Rproj
• Open it in RStudio and your working directory is the project root
• here() keys off this file — it finds the root, then builds paths down from there

# path is relative to the .Rproj root
dt <- fread(here("raw_data", "nsduh.csv"))

• This is why we never write setwd(). The .Rproj sets the location for you
• Double-click project.Rproj to open the project

A Standard Layout

project/
├── project.Rproj    # the here() anchor
├── code/            # scripts + main.r
├── raw_data/        # original data (read-only)
├── temp_data/       # intermediate files
├── outputs/         # tables/ and figures/
├── manuscript/      # the paper
└── README.md        # what & how to run

• Same skeleton every time, so you always know where a thing lives
• New collaborator or RA opens the folder and is oriented in a minute

Raw Data Is Sacred

• raw_data/ holds the original files exactly as they arrived. You never edit them
• No opening the CSV in Excel to “fix” a value. No hand-deleting rows
• Every correction happens in code, reading from raw and writing elsewhere

# read from raw; never write back to it
raw <- fread(here("raw_data", "nsduh.csv"))

# do the fix in code, write elsewhere
clean <- raw[age >= 18]
fwrite(clean, here("temp_data", "adults.csv"))

main.r Ties It Together

The pipeline from W5 lives in code/, run start to finish by main.r.

# code/main.r
library(here)

source(here("code", "01_clean_data.r"))
source(here("code", "02_make_panel.r"))
source(here("code", "03_estimation.r"))
source(here("code", "04_figures.r"))

message("main.r complete")

Method 2: Start from a Template

• A template repository is a pre-built project skeleton you copy to begin
• On GitHub: click “Use this template” to create your own copy, then clone it
• You get the folders, a main.r stub, a .gitignore, and a README on day one
• Every project starts identical, so the structure is never something you forget to set up

The .gitignore

Some files should never go into version control. .gitignore lists them.

# Data: too large for git; add it locally
raw_data/**
!raw_data/**/README.md
temp_data/

# R artifacts
.Rhistory
.RData
.Rproj.user

# OS clutter
.DS_Store

• Code is tracked; data and build artifacts are not
• Raw data is often large or restricted, so it stays local — but the README that explains it is kept
• Intermediate files and figures regenerate from code, so there is no reason to version them

Recap

• A project is one self-contained folder, anchored by .Rproj, so here() and reproducibility just work
• Standard subfolders; raw data is read-only and every fix lives in code
• main.r rebuilds all results from raw data in one run
• Start by hand or from a template; .gitignore keeps data and artifacts out of git