Writing Reproducible R Code for Academic Research

Reproducible doesn't mean well-commented. It means someone else — or you, in a year, on a different machine — can run the code and get the same result without a private, undocumented fix that only lives in your head. That's a higher bar than most research code clears by default, and it's one journals, funders, and dissertation committees are asking to see met more often, not less.

What actually makes R code reproducible

• Pin your package versions — with renv or, at minimum, a recorded sessionInfo() — because CRAN updates can silently change a function's behavior between when you ran the analysis and when someone else tries to rerun it.
• The script is the source of truth, not a saved object. Never rely on a cached .RData file or an intermediate object without the script that produced it — if the script can't regenerate it, it isn't really reproducible, it's just saved.
• Set an explicit seed for anything involving randomness — bootstrapping, cross-validation folds, MCMC sampling — and state what the seed is. Otherwise "reproducible" quietly becomes "reproducible except for the part that involved chance."
• Use a project-based workflow — RStudio Projects, or here::here() — instead of absolute file paths that only resolve on the machine that wrote them.
• Separate data cleaning from analysis into distinct, sequentially numbered scripts, rather than one script that's been edited fifty times and run out of order.
• Never hand-edit data. Every transformation should be a line of code, not a manual spreadsheet fix that leaves no trace of what changed or why.
• Keep raw data raw. Write cleaned output to a separate processed file or folder — never overwrite the original.

Why this is worth doing even under a deadline

It's tempting to skip the reproducibility work when time is short, but the alternative isn't saving time — it's discovering, after the results are already written up, that you can't regenerate a number a reviewer is asking about. At that point it's not a workflow inconvenience anymore, it's a credibility problem, on a much shorter deadline than the one you were trying to protect.

If you want a second set of eyes on your analysis pipeline before it goes into a submission, reproducible R code is something we build into every analysis, not an add-on at the end.

One email whenever we publish something new. No spam, unsubscribe anytime.