forked from tidyverse/style
-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathfunctions.Rmd
More file actions
executable file
·131 lines (99 loc) · 2.71 KB
/
Copy pathfunctions.Rmd
File metadata and controls
executable file
·131 lines (99 loc) · 2.71 KB
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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
# Functions
## Naming
As well as following the general advice for [object names], strive to use verbs for function names:
```{r eval = FALSE}
# Good
add_row()
permute()
# Bad
row_adder()
permutation()
```
## Long lines
If a function definition runs over multiple lines, indent the second line to
where the definition starts.
```{r, eval = FALSE}
# Good
long_function_name <- function(a = "a long argument",
b = "another argument",
c = "another long argument") {
# As usual code is indented by two spaces.
}
# Bad
long_function_name <- function(a = "a long argument",
b = "another argument",
c = "another long argument") {
# Here it's hard to spot where the definition ends and the
# code begins
}
```
## `return()`
Only use `return()` for early returns. Otherwise, rely on R to return the result
of the last evaluated expression.
```{r eval = FALSE}
# Good
find_abs <- function(x) {
if (x > 0) {
return(x)
}
x * -1
}
add_two <- function(x, y) {
x + y
}
# Bad
add_two <- function(x, y) {
return(x + y)
}
```
Return statements should always be on their own line because they have important effects on the control flow. See also [inline statements](#inline-statements).
```{r, eval = FALSE}
# Good
find_abs <- function(x) {
if (x > 0) {
return(x)
}
x * -1
}
# Bad
find_abs <- function(x) {
if (x > 0) return(x)
x * -1
}
```
If your function is called primarily for its side-effects (like printing,
plotting, or saving to disk), it should return the first argument invisibly.
This makes it possible to use the function as part of a pipe. `print` methods
should usually do this, like this example from [httr](http://httr.r-lib.org/):
```{r eval = FALSE}
print.url <- function(x, ...) {
cat("Url: ", build_url(x), "\n", sep = "")
invisible(x)
}
```
## Comments
In code, use comments to explain the "why" not the "what" or "how". Each line
of a comment should begin with the comment symbol and a single space: `# `.
```{r, eval = FALSE}
# Good
# Objects like data frames are treated as leaves
x <- map_if(x, is_bare_list, recurse)
# Bad
# Recurse only with bare lists
x <- map_if(x, is_bare_list, recurse)
```
Comments should be in sentence case, and only end with a full stop if they
contain at least two sentences:
```{r, eval = FALSE}
# Good
# Objects like data frames are treated as leaves
x <- map_if(x, is_bare_list, recurse)
# Do not use `is.list()`. Objects like data frames must be treated
# as leaves.
x <- map_if(x, is_bare_list, recurse)
# Bad
# objects like data frames are treated as leaves
x <- map_if(x, is_bare_list, recurse)
# Objects like data frames are treated as leaves.
x <- map_if(x, is_bare_list, recurse)
```