Naming Conventions and Coding Style

We do not want to impose any specific styles on you, but suggeest to follow the Tidyverse Style Guide for any code you wish to contribute to the package.

You can find all details on https://style.tidyverse.org/.

Function Names

Following the package architecture proposed in the Package-Architecture Wiki Page, the package contains functions with dedicated tasks in the analysis and visualisation flow:

After some careful consideration, we have now decided on the following conventions for naming visR functions. There may be clashes in namespaces that can be omitted by explicitly prefixing the package name to the function call using ::

Granular functions

• visR::estimate: estimator functions (e.g., visR::estimate_KM, visR::estimate_Cox, visR::estimate_MM)
• visR::apply: functions to modify the input data and returned modified version of the input object. This can be modification of the input data such as filtering (e.g., visR::apply_attrition) or to a visualisation (e.g., visR::apply_theme)
• visR::get: functions to obtain specific statistics and derived data (e.g., visR::get_p, visR::get_CI, visR::get_risktable, visR::get_summarytable)
• visR::visr: modular plotting functions without specific styling. There is one base plotting function for defaults (visR::plot), plus explicit functions for specific plot types (visR::plot_barchart, visR::plot_sankey, visR::plot_attrition, ...)
• visR::add: functions to annotate additional data to plots (e.g., visR::add_p, visR::add_CI, visR::add_risktable, ...)
• visR::render: modular rendering functions for tables? could also have explicit cases (not implemented as such yet: visR::render_kable, visR::render_gt, visR::render_dt, ..)

Convenience functions

Convenience functions should start with vr_ and then a descriptive name for the type of analysis, e.g., vr_time_to_event for a function visualising time to event results or vr_attrition for visualising cohort attrition.