1# Google's R Style Guide 2 3R is a high-level programming language used primarily for statistical computing 4and graphics. The goal of the R Programming Style Guide is to make our R code 5easier to read, share, and verify. 6 7The Google R Style Guide is a fork of the 8[Tidyverse Style Guide](https://style.tidyverse.org/) by Hadley Wickham 9[license](https://creativecommons.org/licenses/by-sa/2.0/). Google modifications 10were developed in collaboration with the internal R user community. The rest of 11this document explains Google's primary differences with the Tidyverse guide, 12and why these differences exist. 13 14## Syntax 15 16### Naming conventions 17 18Google prefers identifying functions with `BigCamelCase` to clearly distinguish 19them from other objects. 20 21``` 22# Good 23DoNothing <- function() { 24 return(invisible(NULL)) 25} 26``` 27 28The names of private functions should begin with a dot. This helps communicate 29both the origin of the function and its intended use. 30 31``` 32# Good 33.DoNothingPrivately <- function() { 34 return(invisible(NULL)) 35} 36``` 37 38We previously recommended naming objects with `dot.case`. We're moving away from 39that, as it creates confusion with S3 methods. 40 41### Don't use attach() 42 43The possibilities for creating errors when using `attach()` are numerous. 44 45## Pipes 46 47### Right-hand assignment 48 49We do not support using right-hand assignment. 50 51``` 52# Bad 53iris %>% 54 dplyr::summarize(max_petal = max(Petal.Width)) -> results 55``` 56 57This convention differs substantially from practices in other languages and 58makes it harder to see in code where an object is defined. E.g. searching for 59`foo <-` is easier than searching for `foo <-` and `-> foo` (possibly split over 60lines). 61 62### Use explicit returns 63 64Do not rely on R's implicit return feature. It is better to be clear about your 65intent to `return()` an object. 66 67``` 68# Good 69AddValues <- function(x, y) { 70 return(x + y) 71} 72 73# Bad 74AddValues <- function(x, y) { 75 x + y 76} 77``` 78 79### Qualifying namespaces 80 81Users should explicitly qualify namespaces for all external functions. 82 83``` 84# Good 85purrr::map() 86``` 87 88We discourage using the `@import` Roxygen tag to bring in all functions into a 89NAMESPACE. Google has a very big R codebase, and importing all functions creates 90too much risk for name collisions. 91 92While there is a small performance penalty for using `::`, it makes it easier to 93understand dependencies in your code. There are some exceptions to this rule. 94 95* Infix functions (`%name%`) always need to be imported. 96* Certain `rlang` pronouns, notably `.data`, need to be imported. 97* Functions from default R packages, including `datasets`, `utils`, 98 `grDevices`, `graphics`, `stats` and `methods`. If needed, you can `@import` 99 the full package. 100 101When importing functions, place the `@importFrom` tag in the Roxygen header 102above the function where the external dependency is used. 103 104## Documentation 105 106### Package-level documentation 107 108All packages should have a package documentation file, in a 109`packagename-package.R` file. 110