[R-pkg-devel] Proper way to document helper functions not accessible by user.
Zhian Kamvar
zk@mv@r @ending from gm@il@com
Mon Aug 13 15:27:45 CEST 2018
You can add
#' @noRd
to those functions and roxygen2 will not generate .Rd files for those
entries.
On Mon, Aug 13, 2018 at 2:08 PM Eggleston, Barry <beggleston using rti.org> wrote:
> Hello,
>
> I am working through my first submission and making good progress with the
> CRAN review system, but now I need to understand the best practice for
> dealing with helper functions. I am building a package that only exports
> 12 functions for direct user access, but it has many helper functions not
> directly accessible to the user. In my R code I am using roxygen2 to write
> my help pages. I have written roxygen2 notes to create help pages for
> every function, but for all the helper functions I am using the keyword
> 'internal' so they don't show up in the index of help pages and available
> functions. In future releases I may export these functions for direct
> access, but for now I want to keep them internal. Within each help page of
> these non-accessible helper functions, I have placed '#None' in the
> @examples section, since nobody will be able to call the functions
> directly. In my submission review I was asked to give examples for these
> functions, because my package still has the .Rd files f
> or these helper functions in the submitted .tar.gz file. How do I proper
> handle documentation of these helper functions? Can I remove the roxygen2
> notes that create the .Rd files for these helper functions, so the package
> does not contain .Rd files for them?
>
> Thanks,
> Barry
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
More information about the R-package-devel
mailing list