a small suggestion for improving the building of packages
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