Fixed order of argument descriptions using roxygen

53 Views Asked by At

I am trying to consolidate the documentation for a set of functions. The functions, however, do not have entirely similar argument sets. Rather, they are related in that they act on the same system of tables in a REDCap project.

I've been able to bring all of the functions into the same .Rd file, but I'm not thrilled with how roxygen2 has ordered the arguments in the documentation--that is, in the order in which it finds distinct arguments in the Usage section (see image).

Am I correct that there is no way to force a fixed order of arguments? I haven't found anything yet that has lets me control the ordering.

I would like the arguments to appear in the order

#' @param rcon A \code{redcapConnection} object.
#' @param arms \code{character} or \code{integerish} identifying the arm 
#'   numbers to export or delete.
#' @param data A \code{data.frame} with two columns.  The first column 
#'   (\code{arm_num}) is an integerish value . The second (\code{name}) is
#'   a character value. For backward compatibility, 
#'   this may also be passed as \code{arms_data}.
#' @param override \code{logical(1)}. By default, data will add to or modify 
#'   existing arms data. When \code{TRUE}, all the existing arms data is 
#'   deleted and replaced with the contents of \code{data}.
#' @param refresh \code{logical(1)} If \code{TRUE}, the cached arms data will
#'   be refreshed after the API action is complete.
#' @param ... Arguments to pass to other methods
#' @param error_handling \code{character(1)}. One of \code{c("error", "null")}.
#'   An option for how to handle errors returned by the API.
#'   see \code{\link{redcapError}}.
#' @param config A named \code{list}. Additional configuration parameters to pass to
#'   \code{\link[httr]{POST}}. These are appended to any parameters in
#'   \code{rcon$config}.
#' @param api_param A named \code{list}. Additional API parameters to pass into the
#'   body of the API call. This provides users to execute calls with options
#'   that may not otherwise be supported by \code{redcapAPI}.

enter image description here

1

There are 1 best solutions below

0
Benjamin On

@r2evans provided a link to an issue in the roxygen repository with a work around. (github.com/r-lib/roxygen2/issues/1475)

The solution I have going for now is:

#' @param rcon A \code{redcapConnection} object.
#' @param arms \code{character} or \code{integerish} identifying the arm 
#'   numbers to export or delete.
#' @param data A \code{data.frame} with two columns.  The first column 
#'   (\code{arm_num}) is an integerish value . The second (\code{name}) is
#'   a character value. For backward compatibility, 
#'   this may also be passed as \code{arms_data}.
#' @param override \code{logical(1)}. By default, data will add to or modify 
#'   existing arms data. When \code{TRUE}, all the existing arms data is 
#'   deleted and replaced with the contents of \code{data}.
#' @param refresh \code{logical(1)} If \code{TRUE}, the cached arms data will
#'   be refreshed after the API action is complete.
#' @param ... Arguments to pass to other methods
#' @param error_handling \code{character(1)}. One of \code{c("error", "null")}.
#'   An option for how to handle errors returned by the API.
#'   see \code{\link{redcapError}}.
#' @param config A named \code{list}. Additional configuration parameters to pass to
#'   \code{\link[httr]{POST}}. These are appended to any parameters in
#'   \code{rcon$config}.
#' @param api_param A named \code{list}. Additional API parameters to pass into the
#'   body of the API call. This provides users to execute calls with options
#'   that may not otherwise be supported by \code{redcapAPI}.
#' @usage NULL
#' @order 0

dummyFunctionName <- function(rcon, arms, data, override, refresh, ..., 
                              error_handling, config, api_param){ NULL }

The @usage NULL prevents the usage of dummyFunctionName from being included in the documentation.

The @order 0 places the arguments in dummyFunctionName to be the first ones searched when looking for new arguments names.

The lack of an @export tag prevents dummyFunctionName from being exported.