Best Practices for Writing R Code (2024)

Overview

Keep track of who wrote your code and its intended purpose

Starting your code with an annotated description of what the codedoes when it is run will help you when you have to look at or change itin the future. Just one or two lines at the beginning of the file cansave you or someone else a lot of time and effort when trying tounderstand what a particular script does.

# This is code to replicate the analyses and figures from my 2014 Science# paper. Code developed by Sarah Supp, Tracy Teal, and Jon Borelli

Also consider version-controlling your code as for example taught bySoftware Carpentry’sgit-novice lessons. Frequent commits with explanatory,synoptic commit messages are an elegant way to comment code. RStudioenables this with a Git integration.

Be explicit about the requirements and dependencies of yourcode

Loading all of the packages that will be necessary to run your code(using library) is a nice way of indicating which packagesare necessary to run your code. It can be frustrating to make ittwo-thirds of the way through a long-running script only to find outthat a dependency hasn’t been installed.

library(ggplot2)library(reshape)library(vegan)

Another way you can be explicit about the requirements of your codeand improve it’s reproducibility is to limit the “hard-coding” of theinput and output files for your script. If your code will read in datafrom a file, define a variable early in your code that stores the pathto that file. For example

input_file <- "data/data.csv" output_file <- "data/results.csv"# read inputinput_data <- read.csv(input_file)# get number of samples in datasample_number <- nrow(input_data)# generate resultsresults <- some_other_function(input_file, sample_number)# write resultswrite.table(results, output_file)

is preferable to

# checkinput_data <- read.csv("data/data.csv")# get number of samples in datasample_number <- nrow(input_data)# generate resultsresults <- some_other_function("data/data.csv", sample_number)# write resultswrite.table("data/results.csv", output_file)

It is also worth considering what the working directory is. If theworking directory must change, it is best to do that at the beginning ofthe script.

Error in setwd("~/path/to/working/directory") : cannot change working directory

Identify and segregate distinct components in your code

It’s easy to annotate and mark your code using # or#- to set off sections of your code and to make findingspecific parts of your code easier. For example, it’s often helpful whenwriting code to separate the function definitions. If you create onlyone or a few custom functions in your script, put them toward the top ofyour code. If you have written many functions, put them all in their own.R file and then source those files. sourcewill define all of these functions so that your code can make use ofthem as needed.

source("my_genius_fxns.R")

Other ideas

1. Use a consistent style within your code. For example, name allmatrices something ending in _mat. Consistency makes codeeasier to read and problems easier to spot.

2. Keep your code in bite-sized chunks. If a single function or loopgets too long, consider looking for ways to break it into smallerpieces.

3. Don’t repeat yourself–automate! If you are repeating the samecode over and over, use a loop or a function to repeat that code foryou. Needless repetition doesn’t just waste time–it also increases thelikelihood you’ll make a costly mistake!

4. Keep all of your source files for a projectin the same directory, then use relative paths as necessary toaccess them. For example, use

dat <- read.csv(file = "files/dataset-2013-01.csv", header = TRUE)

rather than:

dat <- read.csv(file = "/Users/Karthik/Documents/sannic-project/files/dataset-2013-01.csv", header = TRUE)

5. R can run into memory issues. It is a common problem to run out ofmemory after running R scripts for a long time. To inspect the objectsin your current R environment, you can list the objects, search currentpackages, and remove objects that are currently not in use. A goodpractice when running long lines of computationally intensive code is toremove temporary objects after they have served their purpose. However,sometimes, R will not clean up unused memory for a while after youdelete objects. You can force R to tidy up its memory by usinggc().

# Sample dataset of 1000 rowsinterim_object <- data.frame(rep(1:100, 10), rep(101:200, 10), rep(201:300, 10))object.size(interim_object) # Reports the memory size allocated to the objectrm("interim_object") # Removes only the object itself and not necessarily the memory allotted to itgc() # Force R to release memory it is no longer usingls() # Lists all the objects in your current workspacerm(list = ls()) # If you want to delete all the objects in the workspace and start with a clean slate

6. Don’tsave a session history (the default option in R, when it asks if youwant an RData file). Instead, start in a clean environmentso that older objects don’t remain in your environment any longer thanthey need to. If that happens, it can lead to unexpectedresults.

7. Wherever possible, keep track ofsessionInfo() somewhere in your project folder. Sessioninformation is invaluable because it captures all of the packages usedin the current project. If a newer version of a package changes the waya function behaves, you can always go back and reinstall the versionthat worked (Note: At least on CRAN, all older versions of packages arepermanently archived).

8. Collaborate. Grab a buddy and practice “code review”. Review isused for preparing experiments and manuscripts; why not use it for codeas well? Our code is also a major scientific achievement and the productof lots of hard work! Reviews are built into GitHub’s Pullrequest feature

cat inflammation.R

# This code runs the inflammation data analysis.source("inflammation_fxns.R")analyze_all("inflammation.*csv")

cat inflammation_fxns.R

# This is code for functions used in our inflammation data analysis.analyze <- function(filename, output = NULL) { # Plots the average, min, and max inflammation over time. # Input: # filename: character string of a csv file # output: character string of pdf file for saving if (!is.null(output)) { pdf(output) } dat <- read.csv(file = filename, header = FALSE) avg_day_inflammation <- apply(dat, 2, mean) plot(avg_day_inflammation) max_day_inflammation <- apply(dat, 2, max) plot(max_day_inflammation) min_day_inflammation <- apply(dat, 2, min) plot(min_day_inflammation) if (!is.null(output)) { dev.off() }}analyze_all <- function(pattern) { # Directory name containing the data data_dir <- "data" # Directory name for results results_dir <- "results" # Runs the function analyze for each file in the current working directory # that contains the given pattern. filenames <- list.files(path = data_dir, pattern = pattern) for (f in filenames) { pdf_name <- file.path(results_dir, sub("csv", "pdf", f)) analyze(file.path(data_dir, f), output = pdf_name) }}