0

This question has been asked before (Include library calls in functions?) but I wonder if there are any new takes on it.

Putting library() calls inside functions is something I am often tempted to do. It means the function is slightly more portable; it will run without errors if a colleague copies it into their own project, for example.

The main downside seems to be "global effects", which I guess refers to namespace clashes. Are there other worries?

The alternatives seem to be:

  • Load packages at the top of the script containing the functions. But how does a colleague who wants to copy the function know which package is required for which function? (I guess the function documentation should cover this?).
  • Build a package. But the ROI on this may be low for small-scale projects.
Kene David Nwosu
  • 828
  • 6
  • 12
  • 3
    One could also explicitly reference the required package in each function call, i.e., `dplyr::mutate()` instead of just `mutate()`. This would make it easier for a secondary user to tell which functions come from which packages. – jdobres Apr 10 '22 at 18:50
  • As a nice side effect of jdobres proposal: You only use functions that you really need and don't import a complete package. – Martin Gal Apr 10 '22 at 21:17
  • *"It means the function is slightly more portable"* I'd generally advise against including any form of `library()` or `require()` call inside a function. If portability is your goal, roll up your functions in an R package and share that (as per your second alternative). This will make sure that dependencies are properly met. Creating an R package for sharing code may seem like overkill, but I'd argue that the opposite is true. Especially small projects & work benefit from being supplemented by (small) R packages that include all major functions and analysis routines, including documentation. – Maurits Evers Apr 10 '22 at 23:30

0 Answers0