Skip to content

Commit

Permalink
Simplified text for folder structure topic
Browse files Browse the repository at this point in the history
  • Loading branch information
njlyon0 committed Feb 22, 2024
1 parent bfaba8a commit 4337b44
Showing 1 changed file with 11 additions and 5 deletions.
16 changes: 11 additions & 5 deletions mod_reproducibility.qmd
Original file line number Diff line number Diff line change
Expand Up @@ -23,17 +23,23 @@ Before we dive into the world of reproducibility for synthesis projects, we thou

## Project Organization & Documentation

Much of the popular conversation around reproducibility centers on reproducibility as it pertains to code. That is definitely an important facet but before we write even a single line it is critically important that we first discuss what factors go into project-wide reproducibility. "Perfect" code in a project that isn't structured thoughtfully can still result in a synthesis project that is not reproducible while even "bad" code can be made more intelligible when it is placed in a well-documented/organized project!
Much of the popular conversation around reproducibility centers on reproducibility as it pertains to code. That is definitely an important facet but before we write even a single line it is vital to consider project-wide reproducibility. "Perfect" code in a project that isn't structured thoughtfully can still result in a project that isn't reproducible. On the other hand, "bad" code can be made more intelligible when it is placed in a well-documented/organized project!

### Folder Structure

The simplest and often most effective way of beginning a reproducible project is adopting (and sticking to) a good file organization system. There is no single "best" way of organizing your projects' files as long as you are consistent. Consistency allows those navigating your system to _deduce_ where particular files are likely to be without having in-depth knowledge of the entire suite of materials.

<img src="images/comic_xkcd-folders.png" alt="One stick figure looks in despair at anther's computer where many badly named files are present. At the bottom text reads 'protip: never look in someone else's documents folder'" width="25%" align="right">

To begin, it is best to have a single folder for each project. This makes it simple to find the project's inputs and outputs and also makes collaboration and documentation much cleaner. Later in your project's life cycle, this 'one folder' approach will also make it easier to share your project with external reviewers or new team members. For researchers used to working alone there can be a temptation to think about your leadership of a project as the fundamental unit rather than the individual projects' scopes. This method works fine when working alone but greatly increases the difficulty of communication and co-working in projects led by teams. RStudio (the primary <u>I</u>ntegrated <u>D</u>eveloper <u>E</u>nvironment for R) and most version control systems assume that each project's materials will be placed in a single folder and either of these systems can confer significant benefits to your work (well worth any potential reorganization difficulty).
<u>The simplest way of beginning a reproducible project is adopting a good file organization system</u>. There is no single "best" way of organizing your projects' files as long as you are _consistent_. Consistency will make your system--whatever that consists of--understandable to others.

Here are some rules to keep in mind as you decide how to organize your project:

1. **Use one folder per project**

Keeping all inputs, outputs, and documentation in a single folder makes it easier to collaborate and share all project materials. Also, most programming applications (RStudio, VS Code, etc.) work best when all needed files are in the same folder.

2. **Organize content with sub-folders**

Within your project folder, it is valuable to structure your folders and files hierarchically. Having a folder with dozens of mixed file types of various purposes that may be either inputs or outputs is cumbersome to document and difficult to navigate. If instead you adopt a system of sub-folders that group files based on purpose and/or source engagement becomes much simpler. You need not use an intricate web of sub-folders either; often just a single layer of these sub-folders provides sufficient structure to meet your project's organizational needs.
Putting files that share a purpose or source into logical sub-folders is a great idea! This makes it easy to figure out where to put new content and reduces the effort of documenting project organization. Don't feel like you need to use an intricate web of sub-folders either! Just one level of sub-folders is enough for many projects.

:::{.callout-warning icon="false"}
#### Discussion: Folder Structure
Expand Down

0 comments on commit 4337b44

Please sign in to comment.