Good Practices

Good practices are essential to ensure the quality of the code, the reproducibility of the results and collaboration. This document provides guidelines to follow for: -

Project Management

RStudio projects

  • Use RStudio projects. RStudio projects should be created when your project was initialized.

  • Do not use setwd, with RStudio projects the working directory should already be set to the right location.

  • Only use relative paths that are contained within your project structure.

Environment

  • Use {renv} to ensure every collaborator use the same version of the packages. Ideally your project should have been set up with {renv}.

Version control

  • Use Git to track changes in your project.

  • Commit often and with meaningful messages.

  • Isolate your work in branches.

Coding

Style

  • Respect coding style.
  • Help yourself and others by using {styler} package (for indentations and line breaks compliance), and {lintr} package for checking style (line length, variable casing, …).
  • Both packages provides easily accessible RStudio Addins (e.g. Style current file, Lint current file).
  • Styling current file will directly reformat your file, while linting your file will tell you where and why your code is not compliant to the defined style. - Both packages and a default .lintr should be ready to use within your project (soon).

Code Organisation and Structure

  • Respect code header (include author, date, …), should be at the very beginning of the script:

    ################################
# Authors:     Name
# Property:     ESQlabs GmbH
# Initial Date: DD.MM.YYYY
# Last updated: DD.MM.YYYY
################################

  • Use sections (commented lines of - or =) to break up your file into easily readable chunks.

    # Load Libraries --------------------

  • Load needed packages at the beginning of the file, in the first section just after the header.

  • Source needed files (for example containing “homemade” functions) just after loading packages in a specific section.

  • Define constant parameters in a specific section just after loading packages or sourcing files.

Comments

  • Comment your code. Explain the “why” not the “what” or “how”.

  • Once your code is finalized remove any commented code from your files.

Functions

  • Generic “homemade” functions that might be needed in various R scripts should be written in a separate file sourced when needed.

  • Avoid having too many nested levels (for loops, …). Try to create functions instead.

Back to top