[Rd] a small suggestion for improving the building of packages

Kevin R. Coombes kevin.r.coombes at gmail.com
Thu Sep 16 23:17:19 CEST 2010


  The phrase that caught my attention in your post is the one about 
"running package.skeleton() over and over".  When I'm developing 
packages, I never run it more than once.  And I usually delete a lot of 
the files it produces (since I like to organize my functions in logical 
batches and  not in separate files).  And once I think I have the file 
structure organized, I put everything under version control and run 
future development out that system.

Can you explain why you would need to re-run package.skeleton()? Is 
there some use case that I am missing?

     Kevin

On 9/16/2010 1:18 PM, Janko Thyson wrote:
> Dear Uwe,
> in principle, I totally agree with your point of politely forcing developers
> to write well documented packages. However, when you're trying to put
> together a package, you (or at least I) never get it completely right on the
> first, say, 20 tries ;-) Yet, by running package.skelleton() over and over
> to keep track of changes you made during the process, you overwrite all Rd
> files each time - including the ones that you might already have put a lot
> of effort into. And delaying documentation to the very end of the process is
> probably not the best idea either ;-) IMHO the community should favor the
> approaches taken by packages such as roxygen or inlinedocs as at least it
> provides some sort of direct synchronization between code and documentation.
> Maybe one could agree on rejecting code that is missing roxygen or inlinedoc
> code, which would ensure that code is documented properly. In fact, isn't
> programming all about automating unnecessary manual procedures? I would
> count starting from scratch with all help files time and time again to be
> one of those unnecessary procedures. This time could better be invested in
> increasing the package's functionality.
>
> Best regards, my thanks go out to everyone as well,
> Janko



More information about the R-devel mailing list