[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