2 Syntax

2.1 Object names

“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

Variable and function names should use only lowercase letters, numbers, and _.

Use underscores (_) to separate words within a name. Base R uses dots in function names (contrib.url()) and class names (data.frame), but it’s better to reserve dots exclusively for the S3 object system. In S3, methods are given the name function.class; if you also use in . function and class names you end up with confusing methods like as.data.frame.data.frame().

Generally, variable names should be nouns and function names should be verbs. Strive for names that are concise and meaningful (this is not easy!).

# Good
day_one
day_1

# Bad
first_day_of_the_month
DayOne
dayone
djm1

Where possible, avoid re-using names of common functions and variables. This will cause confusion for the readers of your code.

# Bad
T <- FALSE
c <- 10
mean <- function(x) sum(x)

2.2 Spacing

Put a space before and after all infix operators (=, +, -, <-, etc.), and when naming arguments 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: don’t use spaces around :, ::, and :::.

# Good
x <- 1:10
base::get

# Bad
x <- 1 : 10
base :: get

Place a space before (, except when it’s part of a function call.

# Good
if (debug) show(x)
plot(x, y)

# Bad
if(debug)show(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 (<-).

list(
  total = a + b + c,
  mean  = (a + b + c) / n
)

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 ) do(x)  # No spaces around debug
x[1,]   # Needs a space after the comma
x[1 ,]  # Space goes after comma not before

2.3 Argument names

A function’s arguments typically fall into two broad categories: one supplies the data to compute on; the other controls details of computation. When you call a function, you typically omit the names of data arguments, because they are used so commonly. If you override the default value of an argument, use the full name:

# Good
mean(1:10, na.rm = TRUE)

# Bad
mean(x = 1:10, , FALSE)
mean(, TRUE, x = c(1:10, NA))

Avoid partial matching.

2.4 Indenting

Curly braces, {}, define the the most important hierarchy of R code. To make this hierarchy easy to see, always indent the code inside {} by two spaces. A { should never go on its own line and should always be followed by a new line. A } should always go on its own line, unless it’s followed by else or ).

# Good
if (y < 0 && debug) {
  message("y is negative")
}

if (y == 0) {
  if (x > 0) {
    log(x)
  } else {
    message("x is negative or zero")
  }
} else {
  y ^ x
}

# Bad
if (y < 0 && debug)
message("Y is negative")

if (y == 0)
{
    if (x > 0) {
      log(x)
    } else {
  message("x is negative or zero")
    }
} else { y ^ x }

It’s ok to drop the curly braces if you have a very simple and short if statement that fits on one line. If you have any doubt, it’s better to use the full form.

y <- 10
x <- if (y < 20) "Too low" else "Too high"

2.5 Long lines

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.

If a function call is too long to fit on a single line, use one line each for the function name, each argument, and the closing ). This makes the code easier to read and to change later.

# Good
do_something_very_complicated(
  "that",
  requires = many,
  arguments = "some of which may be long"
)

# Bad
do_something_very_complicated("that", requires, many, arguments,
                              "some of which may be long"
                              )

You may also place several arguments on the same line if they are closely related to each other, e.g., strings in calls to paste() or stop(). When building strings, where possible match one line of code to one line of output.

# Good
paste0(
  "Requirement: ", requires, "\n",
  "Result: ", result, "\n"
)

# Bad
paste0(
  "Requirement: ", requires,
  "\n", "Result: ",
  result, "\n")

2.6 Assignment

Use <-, not =, for assignment.

# Good
x <- 5

# Bad
x = 5

2.7 Semicolons

Don’t put ; at the end of a line, and don’t use ; to put multiple commands on one line.

2.8 Quotes

Use ", not ', for quoting text. The only exception is when the text already contains double quotes and no single quotes.

# Good
"Text"
## [1] "Text"
'Text with "quotes"'
## [1] "Text with \"quotes\""
'<a href="http://style.tidyverse.org">A link</a>'
## [1] "<a href=\"http://style.tidyverse.org\">A link</a>"
# Bad
'Text'
## [1] "Text"
'Text with "double" and \'single\' quotes'
## [1] "Text with \"double\" and 'single' quotes"