Reputation: 1044
In dplyr
one can write code like e.g. using the '.' to refer to the data in the pipe
x <- data.frame(x = 2:4)
y <- data.frame(y = 1:3)
y %>% dplyr::bind_cols(x,.)
but when using it in a function and running the package check it produces the
no visible binding for global variable '.'.
What is the best practice to handle the NOTE?
Upvotes: 22
Views: 6255
Reputation: 22293
It seems that best practice is to use .data
instead of .
and then use import .data
from the rlang
package. From the programming with dplyr
vignette:
If this function is in a package, using .data also prevents R CMD check from giving a NOTE about undefined global variables (provided that you’ve also imported rlang::.data with @importFrom rlang .data).
Unfortunately that doesn't work for the original question with dplyr::bind_cols
, but it works for example in dplyr::mutate
and dplyr::do
.
Upvotes: 15
Reputation: 3776
Best practice now is to probably use quosures. This other SO post has a good summary: How to evaluate a constructed string with non-standard evaluation using dplyr?
In practice, I've just included . = NULL
at the top of my functions.
EDIT
As @MrFlick pointed out, quosures won't actually help in this case. You can feasibly use quosures to define column names etc. in a way that would allow you to avoid notes about non-standard evaluation in package functions (I haven't done this yet, but it's on my to-do list for at least one of my packages), but you can't actually use this strategy for piping values to a specified argument or position
with .
.
It's worth pointing out that there is at least some overhead with using pipes. It might be that best practice is to not actually use pipes at all in your package functions, which gets around the issue of using .
. For the rest of NSE with dplyr
commands, you can use quosures.
Upvotes: 8