witek
witek

Reputation: 1044

dplyr . and _no visible binding for global variable '.'_ Note in package check

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

Answers (2)

shadow
shadow

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

mikeck
mikeck

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 dplyrcommands, you can use quosures.

Upvotes: 8

Related Questions