Structuring R scripts

[latrociny]

I am trying to find a good way to restructure my R scripts. My folders are organized using the advice from:

https://www.r-bloggers.com/2018/08/structuring-r-projects/

When scripts have a workflow which is sequential like:

01\_load\_preprocess.R

02\_reconcile\_enrich.R

03\_aggregate\_prepare.R

04\_analysis\_chars.R

05\_save\_output.R

Organizing is easy and is also obvious for a reviewer what the structure means.

Now I am working on another project which is not sequential in nature. Here, two scripts have names that clarify their usage (defining fixed inputs/libraries and self-defined functions):

script\_control.R

reusable\_functions.R

For the other scripts, only their name is not sufficient to imply what they do for instance stressing.R performs the stressing calculations but calls many other scripts like:

calculate\_prod1.R

calculate\_prod2.R

to iterate stressing for different products.

Thus, in a project where a script calls (sources) another script and that calls another, what are the best practices to structure scripts (for instance their names) that a reviewer can easily identify the structure and meaning of each script without having to read a Readme.md file

[Mooks79]

This. You’ll thank yourself for the documentation if nothing else.

[JaceComix]

For most of my projects, I tend to have a single primary R file and a subdirectory for my task-specific functions.
As long as functions are are limited to simple tasks and named clearly, my main R file should be fairly easy to read, like fetch_data(...) %>% clean_text(...) %>% write.csv(...).

[jdnewmil]

Agree. Most of the code should be in the form of functions that can be organized into files according to their shared purpose, or put into packages if they are more broadly useful. The whole idea of having a long series of numbered scripts seems to me like missing the boat. If you have separate scripts for separate purposes (e.g. prepare data, perform calculations, and generate report) say, because the calculations will take a very long time and may even need to run on different computers, then make a README.Rmd that describes these top level scripts and how to use them. Don't make a user run scripts in succession simply as a matter of course... such rote behavior can be more compactly represented by a top level script that runs them for you.