Avoiding name clashes: opinion on best practice naming conventions

Dear List,

I'm trying to figure out some best practice way with respect to the naming
conventions when building own packages.

I'd like to minimize the risk of choosing function names that might
interfere with those of other packages (both available ones and those yet to
come).

I came up with following alternatives
1. Prefixing the actual names (e.g. myPkgfoo() instead of foo()): pretty
verbose

Another verbose solution is to use descriptive names for your functions. 
  Then you'll only clash with functions that are trying to do the same 
thing.

2. Emulating a package namespace while developing and explicitly using
myPkg::foo() in all scripts: IMHO the best way, but apparently not possible
as I learned.

Is it really a problem when developing?  Surely you can control which 
other packages are loaded, and just choose names that don't clash with 
those?  The real problem with name clashes comes when your package is 
out in the wild, and a user wants to use your package and an unrelated 
one at the same time.  If you both have a foo() function that user's 
scripts could change depending on the search order.

3. Carefully choosing which functions to export. Yet, I'm not sure I
completely understand the implications of exported functions. Does this
imply that not exported functions cannot interfere with functions in other
namespaces?

You should definitely do this.  Functions which are not exported will 
not be visible to other packages without a prefix, so they won't clash. 
  Your package will be guaranteed to see its own functions first.  A 
user can still have a clash between your exported functions and some 
other package's exports, but with fewer functions exported, that will 
not be as much of a problem.

Duncan Murdoch

I'd be great to hear some recommendations on this one!

Thanks a lot,
Janko

______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel