3 Functions
3.1 Naming
As well as following the general advice for object names, strive to use verbs for function names:
# Good
add_row()
permute()
# Bad
row_adder()
permutation()3.2 Long lines
If a function definition runs over multiple lines, indent the second line to where the definition starts.
# 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
}3.3 return()
Only use return() for early returns. Otherwise, rely on R to return the result
of the last evaluated expression.
# 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.
# 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:
print.url <- function(x, ...) {
cat("Url: ", build_url(x), "\n", sep = "")
invisible(x)
}
3.4 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:
#.Comments should be in sentence case, and only end with a full stop if they contain at least two sentences: