styleguide

Google’s R Style Guide

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

The Google R Style Guide is a fork of theTidyverse Style Guide by Hadley Wickhamlicense. Google modificationswere developed in collaboration with the internal R user community. The rest ofthis document explains Google’s primary differences with the Tidyverse guide,and why these differences exist.

Syntax

Naming conventions

Google prefers identifying functions withBigCamelCase to clearly distinguishthem from other objects.

# GoodDoNothing <- function() {  return(invisible(NULL))}

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

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

We previously recommended naming objects withdot.case. We’re moving away fromthat, as it creates confusion with S3 methods.

Don’t use attach()

The possibilities for creating errors when usingattach() are numerous.

Pipes

Right-hand assignment

We do not support using right-hand assignment.

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

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

Use explicit returns

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

# GoodAddValues <- function(x, y) {  return(x + y)}# BadAddValues <- function(x, y) {  x + y}

Qualifying namespaces

Users should explicitly qualify namespaces for all external functions.

# Goodpurrr::map()

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

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

• Infix functions (%name%) always need to be imported.
• Certainrlang pronouns, notably.data, need to be imported.
• Functions from default R packages, includingdatasets,utils,grDevices,graphics,stats andmethods. If needed, you can@import the full package.

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

Documentation

Package-level documentation

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