1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
|
# Google's R Style Guide
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](https://style.tidyverse.org/) by Hadley Wickham
[license](https://creativecommons.org/licenses/by-sa/2.0/). 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.
## Syntax
### Naming conventions
Google prefers identifying functions with `BigCamelCase` to clearly distinguish
them from other objects.
```
# Good
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.
```
# Good
.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()
The possibilities for creating errors when using `attach()` are numerous.
## Pipes
### Right-hand assignment
We do not support using right-hand assignment.
```
# Bad
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 returns
Do not rely on R's implicit return feature. It is better to be clear about your
intent to `return()` an object.
```
# Good
AddValues <- function(x, y) {
return(x + y)
}
# Bad
AddValues <- function(x, y) {
x + y
}
```
### Qualifying namespaces
Users should explicitly qualify namespaces for all external functions.
```
# Good
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.
## Documentation
### Package-level documentation
All packages should have a package documentation file, in a
`packagename-package.R` file.
|
