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())