In this document, you'll find some best practices that we have researched for R projects. Of course, this is an opinionated list. Still, we strongly encourage you to follow those best practices to the best of your ability. It is also very useful to know them in case you end up in a job where those best practices are observed.
Here are some packages that will make it easier to maintain clean code and ensure working environments.
You can also adapt the default tidyverse style to your liking (e.g. different identation). What matters is the consistency.
There is no standard CorrelAid way to structure R projects yet. We have collected some blog posts and resources here which can give you some good ideas.
Different options exist to name your objects. The typical convention in R is to use snakecase (e.g.
my_obj) except in Shiny where camelCase is more common. In either way, the important thing is consistency! So decide in your team what style you want to use and then stick with it!
Artwork by @allison_horst
Reports and other textual outputs should be written using RMarkdown to ensure reproducibility and to facilitate proper version control. In certain circumstances, formats like Microsoft Word can be acceptable, e.g. for providing documentation in a familiar format to non-profit partners.
- PDF if the organisation needs to provide a report to a third party (e.g. as part of reporting for a grant)
If you haven't worked with RMarkdown before:
Embrace the workflow of RMarkdown driven development
-> most CorrelAid reporting projects should aim for the project stage.
Flexdashboards without runtime Shiny have the big advantage over Shiny dashboards and flexdashboards with Shiny that they can be instantly knitted to a static HTML. No server required. Hence, this is the recommended solution if data is fixed (or only updated rarely) and interactivity needs are not high. If new data is added in the future, the organization must be enabled to re-knit the document themselves in the future. So instead of a "hosting problem", we have a knowledge transfer problem in this case. Still, proper documentation, good handover workshops and technologies that ensure stable environments (Docker, renv) can help with solving this problem.
If you decide that yes, Shiny will best solve the problem at hand, here are some best practices to follow:
Flexdashboard with runtime Shiny is a way to design simple dashboards using RMarkdown while still making use of Shiny interactivity (i.e. inputs and outputs). This can be useful if you only want to build a small dashboard and you're satisfied with the design that flexdasbhoard has.
Flexdashboards with runtime Shiny still require a server, so they do not solve the "hosting problem". It is rather a different way to write Shiny apps.