(Adapted from http://r-pkgs.had.co.nz/r.html#style)

We use camelCase in R. Function and variable names all start with lowercase. Package names start with uppercase.

Examples:

• cohortData ← loadCohortData(“myFolder”)
• The SqlRender package

Function names typically start with a verb. Variable names are typically nouns.

Place spaces around all infix operators (=, +, -, ←, etc.). The same rule applies when using = in function calls. Always put a space after a comma, and never before (just like in regular English).

Good

average ← mean(feet / 12 + inches, na.rm = TRUE)

Bad

average←mean(feet/12+inches,na.rm=TRUE)

There’s a small exception to this rule: :, :: and ::: don’t need spaces around them.

Good

x ← 1:10

base::get

Bad

x ← 1 : 10

base :: get

Place a space before left parentheses, except in a function call.

Good

if (debug) {
  do(x)
}

plot(x, y)

Bad

if(debug){
  do(x)
}

plot (x, y)

Extra spacing (i.e., more than one space in a row) is ok if it improves alignment of equal signs or assignments (←).

Do not place spaces around code in parentheses or square brackets (unless there’s a comma, in which case see above).

Good

if (debug) {
  do(x)
}

diamonds[5, ]

Bad

if ( debug ) {  # No spaces around debug
  do(x)
}

x[1,]   # Needs a space after the comma
x[1 ,]  # Space goes after comma not beforeCurly braces

An opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed by else.

Always indent the code inside curly braces. It’s ok to leave very short statements on the same line:

if (y < 0 && debug) {
  message("Y is negative") Line length
}

Strive to limit your code to 80 characters per line. This fits comfortably on a printed page with a reasonably sized font. If you find yourself running out of room, this is a good indication that you should encapsulate some of the work in a separate function.

When indenting your code, use two spaces. Never use tabs or mix tabs and spaces. Change these options in the code preferences pane.

The only exception is if a function definition runs over multiple lines. In that case, indent the second line to where the definition starts.

Use ←, not =, for assignment.

Good

x ← 5

Bad

x = 5

If-then-else clauses should always use curly brackets, even if there's only one clause and it's one statement.

Good

if (a == b) {
  doSomething()
}

Bad

if (a == b) doSomething()

When calling a function that has more than one argument, make sure to refer to each argument by name instead of relying on the order of arguments.

Good

translateSql(sql = “COMMIT”, targetDialect = “PDW”)

Bad

translateSql(“COMMIT”, “PDW”)

Comment your code. Each line of a comment should begin with the comment symbol and a single space: #. Comments should explain the why, not the what.

Use commented lines of - and = to break up your file into easily readable chunks.

# Load data —————————

# Plot data —————————

Opening curly brackets should precede a new line. A closing curly bracket should be followed by a new line except when it is followed by else or a closing parenthesis.

Good

if (a == b) {
  doSomething()
} else {
  doSomethingElse()
}

Bad

if (a == b) 
{
  doSomething()
} 
else 
{
  doSomethingElse()
}