I’m interested in getting some more discussion going around what might be considered best practice in terms of naming conventions for the exported functions of R packages.
Of particular interest is whether and when the
object_verb naming strategy is suitable. This type of prefixing is evident in packages like
I think the two main advantages of this are that it:
- facilitates tab completion and the discovery of functions - especially for interactive use when it’s common for packages to be loaded upfront with
- helps avoid the potential for namespace conflicts with other packages that use similar verbs (e.g. API packages)
I’m in favour of this approach, and it is also encouraged in ROpenSci’s packaging guide. However, it seems like it could also be slightly controversial (e.g. some feel this is essentially a namespacing issue and prefixing is a dirty workaround). Please see my blog post for more background on this:
In terms of framing the discussion, I’d like to point people to this article by Francois Chollet, the author of Keras (thanks to @jennybryan for sharing this!). Some parts of it apply more directly to naming conventions than others, but I think it is an excellent resource and I am all for encouraging a “design culture” among R developers.
My sense is that a “design culture” means that sometimes we may need to be a little flexible with certain development principles in favour of making things more useable for both ourselves and others. Purists may disagree with that, but one of the things which makes R a great language is the ongoing interaction between R users and (package) developers, and the fact that many of us wear both hats (almost) interchangeably. This is underpinned to a large extent by some of the design intent for R (and S) as highlighted by @jcheng in this interview:
R is not a DSL. It’s a language for writing DSLs, which is something that’s altogether more powerful.
By the way - that whole interview is well worth the read if you haven’t seen it before and much of it is also relevant to the framing of this discussion. Especially the latter parts about comparing R to other languages, and the influence of computer science and software engineering making its way into R.