Google’s R Style Guidetoto

R is a high-level programming language used primarily for statistical computing and graphics. The goal of the R Programming Style Guide is to make our R code easier to read, share, and verify.

The Google R Style Guide is a fork of the Tidyverse Style Guide by Hadley Wickham license. Google modifications were developed in collaboration with the internal R user community. The rest of this document explains Google’s primary differences with the Tidyverse guide, and why these differences exist.

Syntaxtoto

Naming conventionstoto

Google prefers identifying functions with BigCamelCase to clearly distinguish them from other objects.

# Goodtoto

DoNothing <- function() {
  return(invisible(NULL))
}

The names of private functions should begin with a dot. This helps communicate both the origin of the function and its intended use.

# Goodtoto

.DoNothingPrivately <- function() {
  return(invisible(NULL))
}

We previously recommended naming objects with dot.case. We’re moving away from that, as it creates confusion with S3 methods.

Don’t use attach()toto

The possibilities for creating errors when using attach() are numerous.

Pipestoto

Right-hand assignmenttoto

We do not support using right-hand assignment.

# Badtoto

iris %>%
  dplyr::summarize(max_petal = max(Petal.Width)) -> results

This convention differs substantially from practices in other languages and makes it harder to see in code where an object is defined. E.g. searching for foo <- is easier than searching for foo <- and -> foo (possibly split over lines).

Use explicit returnstoto

Do not rely on R’s implicit return feature. It is better to be clear about your intent to return() an object.

# Goodtoto

AddValues <- function(x, y) {
  return(x + y)
}

# Badtoto

AddValues <- function(x, y) {
  x + y
}

Qualifying namespacestoto

Users should explicitly qualify namespaces for all external functions.

# Goodtoto

purrr::map()

We discourage using the @import Roxygen tag to bring in all functions into a NAMESPACE. Google has a very big R codebase, and importing all functions creates too much risk for name collisions.

While there is a small performance penalty for using ::, it makes it easier to understand dependencies in your code. There are some exceptions to this rule.

  • Infix functions (%name%) always need to be imported.
  • Certain rlang pronouns, notably .data, need to be imported.
  • Functions from default R packages, including datasets, utils, grDevices, graphics, stats and methods. If needed, you can @import the full package.

When importing functions, place the @importFrom tag in the Roxygen header above the function where the external dependency is used.

Documentationtoto

Package-level documentationtoto

All packages should have a package documentation file, in a packagename-package.R file.