22

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?

NelsonGon
  • 13,015
  • 7
  • 27
  • 57
witek
  • 984
  • 1
  • 8
  • 25

2 Answers2

14

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.

shadow
  • 21,823
  • 4
  • 63
  • 77
  • Thank you. Seems like the way to go. As soon as I tried it I will accept your answer. Have a great day. – witek Jul 31 '18 at 07:03
  • 2
    It does not work either with e.g. `all_vars(. < 3)` applications or `any_vars(. < 4)` etc. – witek Nov 16 '21 at 09:00
8

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.

mikeck
  • 3,534
  • 1
  • 26
  • 39
  • 4
    using `utils::globalVariables(".")` also works, but I'm not a big fan of it. I worry that this might prevent a meaningful message when `.` gets used inappropriately. I don't know what that might look like...I'm just generally paranoid. – Benjamin Feb 12 '18 at 15:52
  • How would using a quosure help here? Don't those just use symbols as parameters as well? Won't those still be undefined? – MrFlick Feb 12 '18 at 15:53
  • @MrFlick, you're right---your can use quosures for named columns and such, but there isn't a great way to deal with `.` itself. – mikeck Feb 12 '18 at 17:03