R Style Guide

R is a high-level programming language used primarily for statistical computing and graphics. R does not have any well defined coding recommendations or de facto standards. This style guide provides some recommendations based on personal experience and expert opinions (see Additional Guides). Use your best judgement and common sense when deciding whether to adhere to these recommendations. Be consistent. Use style to enhance legibility. Ultimately, a unified style will help make collaboration and sharing code easier.

File Names

• Use a meaningful and descriptive names
• End in .R
• Preferably use camelCase
• If necessary, separate words by _ not .

# Good
getData.R

# Acceptable
get_data.R
	
# Bad
foo.bar.r
89317240934735.r

Identifiers

• Use meaningful and descriptive names
• For functions, strive to use verbs in names
• Variables should preferably adhere to camelCase. But for backward compatibility with historical functions, all lower case letters and words separated with . is also accepted
• Function and class names should adhere to camelCase
• Do not use . with class names due to potential confusion with S3 method declarations
• Do not use _ or - with identifiers

# Good
pcaEmbedding  # variable
getPcaEmbedding <- function()  # function

# Acceptable
pca.embedding
getEmb <- function() 

# Bad
pca_embedding
get_pca_embedding <- function()
get.pca.embedding <- function() 

# Really bad
pe
gpe <- function()
foo-bar <- function()

General Syntax

• To indent, use 4 spaces not tabs
• For assignments, use <- not =
• Do not use ;

# Good 
x <- 23
y <- 12

# Bad
x = 23; y = 12
23 -> x

Spacing

• Place spaces around all binary operators such as =, +, -, <-, etc.
• Place a space before the (, except in a function call
• Use space after a comma

# Good
someFunction <- function(a, b, c, d = 100) {
    if (a < d) {
        a <- (b + c) * d
    }
}

# Bad
someFunction <- function(a,b,c,d= 100) { 
  if(a<d) a<-(b+c)*d 
}

Curly Braces

• Do not place { on its own line
• Place } on its own line unless followed by else
• Surround else statements with curly braces

# Good
if (a < d) {
    a <- (b + c) * d
} else {
    a <- d
}

# Bad
if (a < d) 
{
    a <- (b + c) * d
} else a <- d

Line Length

• Keep each line less than 80 characters
• Align lines by shared features like parameters if possible

# Good
someFunction(optionA = alpha,
             optionB = bravo,
             optionC = charlie,    
             optionD = delta)

# Acceptable
someFunction(optionA = alpha,
    optionB = bravo, optionC = charlie,    
    optionD = delta)

# Bad
someFunction(optionA = alpha, optionB = bravo, optionC = charlie, optionD = delta)

Commenting

• General comments should be identified with # followed by a space
• Inline comments need 2 spaces before the #
• Function and object descriptions should adhere to roxygen guidelines
• Separate function comments and function code with blank line
• Functions from previous code using 2 blank lines

#' Add together two numbers.
#' 
#' @param x A number.
#' @param y A number.
#'
#' @return The sum of x and y.
#'
#' @examples
#' add(1, 1)
#' add(10, 1)
#'
add <- function(x, y) {
    # general comment
    x + y  # inline comment
}


#' Next function

Loops

• Use seq(along = x) to protect against instances where x is empty
• Use apply, lapply, etc when possible

# Good
lapply(seq(along = x), function(i) {
    doSomething(i)
})

# Acceptable
for (i in seq(along = x)) {
    doSomething(i)
}

# Bad
for (i in 1:length(x)) {
    doSomething(i)
}

Repeat

• Use repeat for better interpretability

# Good
repeat {
    ...
}

# Bad
while (TRUE) {
    ...
}

Additional Guides

The tidyverse style guide by Hadley Wickham

(an older) R Style Guide by Hadley Wickham

Google's R Style Guide

R Coding Conventions by Henrik Bengtsson

Bioconductor Coding Style

Inspiration

Code Guide by mdo