Skip to content
Prev 54707 / 63424 Next

Best practices in developing package: From a single file

Dear Duncan,

With all respect, but I strongly disagree on your stance regarding roxygen2
for multiple reasons:

1. It is in my humble opinion not correct to evaluate a tool based on the
abuse of some users. It's not because people write packages with bad
documentation, that roxygen2 is to blame. I use roxygen2, and I care a
great deal about documentation. So I actually took a bit offense there.

2. Writing .Rd files directly means that you have to write out the usage
yourself, know the different tags needed for documenting different types of
generics and methods, and so forth. It means a lot more iterations to get
every tag right so that R CMD check does not complain any more. It requires
a more detailed knowledge of the entire Rd tag system compared to letting
roxygen2 do the standard work for you. So one could argue that the extra
knowledge required would actually hinder starting developers to write good
documentation as opposed to help them.

3. given your criticism, I'd like your opinion on where I can improve the
documentation of https://github.com/CenterForStatistics-UGent/pim. I'm
currently busy updating the help files for a next release on CRAN, so your
input is more than welcome.

I'm not going to force anyone to use roxygen2. But I personally find it
easier to have the function right below the documentation, so that any
change to the function can immediately be documented as well. You prefer to
do this by keeping that strictly separated, which is absolutely fine. It's
just not my prefered workflow. Different animal, different habits I guess.

On a sidenote: I had a lot of complaints about earlier iterations of
roxygen2 and the many changes to tags and their meanings, but the roxygen2
package matured in the meantime and has been a stable and reliable tool for
me the past years.

Kind regards
Joris



On Tue, Jan 30, 2018 at 8:53 PM, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

  
    

Thread (25 messages)

Suzen, Mehmet Best practices in developing package: From a single file Jan 30 Brian G. Peterson Best practices in developing package: From a single file Jan 30 Duncan Murdoch Best practices in developing package: From a single file Jan 30 Cook, Malcolm Best practices in developing package: From a single file Jan 30 Dirk Eddelbuettel Best practices in developing package: From a single file Jan 30 Kenny Bell Best practices in developing package: From a single file Jan 30 Suzen, Mehmet Best practices in developing package: From a single file Jan 30 Suzen, Mehmet Best practices in developing package: From a single file Jan 30 Duncan Murdoch Best practices in developing package: From a single file Jan 30 Duncan Murdoch Best practices in developing package: From a single file Jan 30 Hadley Wickham Best practices in developing package: From a single file Jan 30 Hadley Wickham Best practices in developing package: From a single file Jan 30 Joris Meys Best practices in developing package: From a single file Jan 31 Duncan Murdoch Best practices in developing package: From a single file Jan 31 Duncan Murdoch Best practices in developing package: From a single file Jan 31 Duncan Murdoch Best practices in developing package: From a single file Jan 31 Dirk Eddelbuettel Best practices in developing package: From a single file Jan 31 Joris Meys Best practices in developing package: From a single file Jan 31 Mark van der Loo Best practices in developing package: From a single file Jan 31 Pfaff, Bernhard Dr. Best practices in developing package: From a single file Jan 31 Yihui Xie Best practices in developing package: From a single file Jan 31 Michael Lawrence Best practices in developing package: From a single file Jan 31 Suzen, Mehmet Best practices in developing package: From a single file Jan 31 Gabriel Becker Best practices in developing package: From a single file Jan 31 Duncan Murdoch Best practices in developing package: From a single file Jan 31