Could I get some feedback on a few function names?

Package development
#1

… before I submit my package to CRAN. This is highly subjective and probably not so important but any opinion is welcome.

I've a function orcid() that controls the appearance of ORCID icons. The name is a bit ambiguous. Can't use orcid_icon() because it conflicts with a parameter. Not a fan of prefixing the parameter with a dot here. Do you find orcid() clear enough or would you rename it? E.g. using the package abbreviation at the beginning: plm_orcid_icon() which is a bit long.

There's also a to_yaml() method that pushes tabular data to YAML headers. Although a bit less specific than to_yaml(), I'm tempted to rename it push() because that's a usual function name in some languages to inject data in objects. Any preference?

#2

My personal preference is to name functions verb_object to suggest what action is to be performed and what kind of object are candidates. So if were me, I'd go with something like style_orcid()

As for push() there's going to be some mental friction remembering this has nothing to do with git and at some point stacks will become the rage and we will have push() and pop() intruding in head space. Combining with my first principle, I'd think push_to_yaml().

2 Likes
#3

Thank you very much for your feedback.

I agree that verb_object is usually the preferred way of naming functions. Here, the function is like a modifier so a noun is good choice IMO. My issue is the ambiguity with the name orcid. Does it refer the ORCID icon, identifier, link? I wonder if people would get confused by it. style_orcid() doesn't resolve that ambiguity. I could name it style_orcid_icon() but that would probably be unnecessarily long.

Good point for push(). I'll keep to_yaml() then. I guess the name is explicit enough that I can omit the push_ prefix.

1 Like