Following a particular programming style will help programmers read and understand source code conforming to the style, and help to avoid introducing errors. Here we present a small list of guidelines on what is considered a good practice when writing R code in Giotto package. Most of them are adapted from Bioconductor - coding style or Google’s R Style Guide. These guidelines are preferences and strongly encouraged!
# package installations
BiocManager::install("biocthis")
install.packages("styler")
# styling a file
b_style <- biocthis::bioc_style()
styler::style_file(path = "[???]", transformers = b_style)
# styling the active package (may lead to lots of conflicts)
# generally only run by core devs
styler::style_pkg(transformers = b_style)exported - Core functionality for users to directly use. These should have clear names and documentation
exported utility - Secondary functionalities that are helpful to also have available, but are not directly related to data processing, analysis, and visualization. Examples are dt_to_matrix() or wrap_msg(). Another reason for this type of function is because Giotto is modular and some functions that are not expected to be commonly used by end users also need to be exported so that they are available across the Giotto ecosystem.
internal - Functions that are never intended to be used outside of a module package. These are functions only relevant to the internals of one package, for example .detect_in_dir() from Giotto’s internals which is pretty nondescript and mainly there to help with code organization.
Use camelCase for exported functions. ex: functionName()
Use snake_case for exported utiliity functions. ex: function_name()
Use . prefix AND snake_case for internal functions. ex: .function_name()
Use snake_case for parameter/argument names.
Never use . as a separator in function naming. (in the S3 class system, fun(x) where x is class foo will dispatch to fun.foo())