Why File Organization Matters
A statistical analysis is easier to repeat when someone can tell which data were used, which files were changed, and how the reported outputs were made. Even a careful script can be difficult to use if it points to a vaguely named spreadsheet among several similarly named copies. A clear project structure makes the path from inputs to results visible.
The goal is not to create the largest possible collection of folders or to save every intermediate click. It is to make the project understandable without relying on one person’s memory. A reader should be able to identify the original data, locate the code and documentation, and find the outputs without guessing.
A Practical Project Folder Structure
Start with one main folder for the project. Within it, give distinct roles to the main kinds of files. For example:
- data_raw contains original data files as received or collected. Keep these unchanged.
- data_clean contains data files created by cleaning or transforming the raw data.
- code contains scripts or other files that carry out data processing and analysis.
- documentation contains explanatory material, such as a project readme or a record of data sources and file conventions.
- output contains results created by the work, such as tables, figures, or reports.
The folder names are examples rather than required terms. What matters is using names consistently and keeping different roles distinct. A project might use “analysis” instead of “code,” for instance, if that name is clear to everyone working on it.
This organization also makes the direction of work easier to see: original data are inputs; cleaned data and analysis files are produced during the project; outputs are results. A file should not appear to be an original input merely because it is a spreadsheet, nor should a result be mixed in with the source data.
| Project area | Typical contents | Useful distinction |
|---|---|---|
| data_raw | Original data files | Preserve these as received; do not treat them as working copies. |
| data_clean | Prepared data files | These are derived from inputs and may change as the workflow develops. |
| code | Scripts and related code files | These describe or perform the steps used to create later files. |
| documentation | Readme, source information, and file notes | Explain the project’s organization and conventions. |
| output | Tables, figures, and reports | These are results, not inputs to be mistaken for original data. |
A readme is especially useful when it answers practical orientation questions: What is this project about? Where did the data come from? What are the main folders for? Which script should be run, and what files does it use or create? Keep explanations concise and accurate. A readme should not claim that a file is current if the folder contains a different version.
Worked Example: Setting Up a New Project
A student is beginning a hypothetical project that will analyze a small survey file supplied by an instructor. The file is named survey_export.csv. The student expects to make a cleaned data file, write a script, and produce a summary table and figure. A suitable project layout is:
Project folder: campus_survey
Main folders: campus_survey/data_raw, campus_survey/data_clean, campus_survey/code, campus_survey/documentation, and campus_survey/output.
The student places the unchanged survey_export.csv in data_raw. The cleaning script belongs in code, and the cleaned data file it creates belongs in data_clean. The summary table and figure belong in output. The documentation folder holds a short readme that describes the folder roles and identifies the script used to create the analysis files.
This setup does not require the student to remember whether survey_export.csv was edited. Its location signals that it is the original input; the separate cleaned-data folder provides a place for a derived file. The script and output are also separated from both. If someone else opens the project, the structure gives a reasonable starting point for tracing how the results were produced.
Choose File Names That Carry Useful Information
A useful file name is descriptive enough to distinguish a file from its neighbors without becoming a paragraph. A consistent pattern might include the project or subject, the file’s contents, a date when relevant, and a version or status label. For dates, use the year-month-day order, such as 2026-10-12. This keeps dates unambiguous and makes names sort in calendar order.
For example, a cleaned survey file might be named campus_survey_clean_2026-10-12.csv. A script might be named clean_campus_survey.R, and a figure might be named campus_survey_response_summary_2026-10-12.png. These names indicate content or purpose. Where a file is a version of a changing work product, a clear version label such as v01 or v02 can be useful.
Avoid names that rely on a person’s memory or imply a status that may quickly become outdated. Names such as new.csv, latest.csv, use_this_one.csv, or final_final.csv do not explain what distinguishes the file. Similarly, a date in a file name should have a defined meaning within the project. It could indicate when a report was created or when a data file was prepared; do not leave collaborators to infer which.
Keep names simple and consistent. Using underscores between words, avoiding unexplained abbreviations, and applying the same order of name elements across related files can make a folder easier to scan. File extensions should match the actual format: a comma-separated data file should retain its appropriate extension, rather than being renamed to look like a different file type.
Worked Example: Replacing Ambiguous Names
A hypothetical project folder contains three files named survey.csv, survey_new.csv, and survey_final.csv. The team cannot tell whether they are raw data, cleaned data, or later revisions. They agree on the naming pattern “project_role_date_version” where a date or version is useful.
The original input is renamed for clarity as campus_survey_raw.csv and placed in data_raw. A prepared data file is named campus_survey_clean_2026-10-12_v01.csv and placed in data_clean. A revised cleaned file, made later from an updated script, is named campus_survey_clean_2026-10-15_v02.csv.
The names and locations now communicate two different facts: “raw” versus “clean” describes each file’s role, while the date and version distinguish successive prepared files. The original input remains separate and unchanged. The team should still document which cleaned file is used in a particular analysis; the name alone does not prove that it is the right input.
Manage Versions Without Losing Earlier Work
A new version is warranted when a change creates a meaningfully different file that someone may need to identify or compare with an earlier one. For example, a changed cleaning rule may produce a different cleaned data file; an updated analysis may produce a new report. The version label should make the relationship between those files understandable.
Do not create a new copy for every temporary edit if the extra copies will confuse rather than clarify. Instead, decide what counts as a meaningful change for the project and apply that rule consistently. Keep the earlier version when it is needed to understand or reproduce prior work. If an earlier file is no longer needed, follow the project’s storage and retention practices rather than keeping unexplained duplicates indefinitely.
Never use a name like “final” as a substitute for version information when later changes are possible. If a report has been revised, use a dated or numbered name, such as campus_survey_report_v02.pdf, and make clear which version is being shared. Avoid silently saving new contents over the only copy of a file needed to understand an earlier result.
A folder system and naming scheme do not replace scripts or documentation. Names help people find and distinguish files; code records executable steps; documentation explains relevant context. For reproducible work, these pieces need to agree. A script that reads data_clean/campus_survey_clean_v01.csv should not be accompanied by a note claiming it uses v02.
Worked Example: Revising an Analysis Output
A hypothetical analyst has a report named clinic_wait_summary_v01.pdf, created from a script and a cleaned data file. The analyst later corrects the script’s labeling and regenerates the report. The numerical results do not change, but the report is a revised deliverable.
The analyst saves the revised report as clinic_wait_summary_v02.pdf rather than overwriting v01. The script is saved in the code folder with a name that describes its purpose, and the documentation records which cleaned data file and script version produced each report when that distinction matters.
This preserves a way to identify the earlier deliverable and makes the revised one distinguishable. If the revision had instead changed the data preparation, the new cleaned file and the new output would both need clear identities so that the report’s inputs can be traced. In either case, a version number is useful only when it is applied consistently and the relationship between versions is clear.
A Short Justification: Make the File Path of the Work Visible
Reproducibility depends on being able to connect a result to the files and steps that produced it. In a well-organized project, that connection can be followed in order: an original input is kept in its designated location; code works from that input or from a clearly identified derived file; and resulting outputs are stored separately. Documentation helps explain the links when the folder names alone are not enough.
If raw and cleaned data are mixed together, the first link becomes uncertain: a reader may not know which file is original. If scripts and outputs are mixed, it becomes harder to identify which file performs the work and which file is its result. Separating these roles reduces those ambiguities. It does not guarantee that an analysis is correct, but it makes the project’s materials easier to locate and the workflow easier to inspect.
Common Mistakes and Practical Checks
- Using one folder for everything. The wrong reasoning is that a small project does not need organization. The correction is to create a few role-based folders even for a small project; a simple structure is easier to maintain than a pile of ambiguous files.
- Editing the original input. The wrong reasoning is that saving changes into the first spreadsheet is faster. The correction is to preserve original data and put derived or cleaned files in a separate location.
- Calling a file “final.” The wrong reasoning is that the current version is probably the last one. The correction is to use a consistent date or version label when successive files need to remain distinguishable.
- Keeping multiple unexplained copies. The wrong reasoning is that more copies always make work safer. The correction is to retain versions that have a clear purpose and identify their roles; otherwise duplicates make it harder to know which file is relevant.
- Assuming a clear name is a complete record. The wrong reasoning is that a file name alone explains its source and processing history. The correction is to use names with folder placement, code, and documentation so the relationship among files can be understood.
Check Your Understanding
Try these questions without looking back.
- Where should an unchanged data file received from a collaborator be stored, and why should it be kept distinct from a cleaned file?
- Give a file name for a hypothetical second version of a cleaned data file. State what the date or version label in your name means.
- A folder contains analysis scripts, figures, and source data together. Suggest a clearer set of folder roles for these files.
- Why is “final_final.csv” a poor name for a file that may be revised again?
- What does a clear folder structure help a reader do, and what does it not guarantee about the analysis?