Feature requests and collaboration to DAISIE are encouraged. To ensure the consistency and quality of the code when so many collaborators are working on the same codebase, certain conventions must be followed. External pull-requests will be rejected or changes will be required if these conditions are not met. If this happens, please be aware that this is in no way personal, and be sure that we appreciate your interest in DAISIE, rather, we enforce these rules to ensure the package is as readable and bug-free as we can make it.
Files and functions in their own file for functions start with the prefix DAISIE_
.
Helper functions can go into files but do not have to start with the prefix DAISIE_
but will be stored within a DAISIE_ prefixed file owing to point 1.
devtools::lint()
, this will examine the DAISIE package to check code is in line with the style guide and give corrections if an error in style exists.Cover new functions with a unit test. Unit tests function as both a way to ensure new functions behave as expected, and as an internal form of documentation. Unit tests cover things such as: the correct type is returned when a function is called correctly, boundary cases behave as expected, and simple, short runs of the function return the expected, correct output. A helper function for unit testing is available in usethis::use_test()
. When the cursor is on the function requiring testing, a new file with skeleton code for testing will be generated.
Test coverage can be calculated using the function devtools::test_coverage()
. This will produce a window with each function’s coverage across the whole package.
All new functions must have (at least) 100% coverage.
Integration tests are encouraged. Integration tests, unlike unit tests, test the functionality of the package in a more unified way. Examples of integration testing include testing an entire ML routine. Because integration tests generally much slower to run, we request that these be skipped on local builds and only run on Travis CI. Care should still be taken to balance the test’s speed and usefulness, so do try to make it as fast as possible. If this is still impossible, a final option is to include said integration test in DAISIE’s sister package DAISIEtesting, built specifically for this purpose.
Use the R package roxygen2
to document the package and the individual functions. Use devtools::document()
to write the NAMESPACE. The functions are documented using the shortcut Ctrl
+ Alt
+ Shift
+ R
while the cursor is over the function name. This will write the skeleton for the function documentation into which you can write the function description and parameters, etc.
Every function needs to have documentation. This includes helper or secondary functions. Internal functions that do not require an explicit documentation entry in the CRAN manual, should be marked with @keyword Internal
to ensure that developer documentation is still accessible, while preventing unnecessary clutter for the user in the manual.
Parameter documentation is written in the default_params_doc.R
and called by each function. Thus, each individual function’s roxygen block should NEVER have any @param
field, but instead have @inheritParams default_params_doc
.
All exported functions should be accompanied by runnable and easy to read examples that document all possible flows of code. This means that if a simulation can be run in the IW or CS modes, for instance, example code should be provided for both methods. In the very rare cases when running an example is not possible, e.g. it is virtually impossible to make the code fast, or an error is expected, please write the example anyway and encapsulate it with the \dontthest{}
or \dontrun{}
tags respectively.
Authorship/blame. Any direct or indirect contributor to a piece of code should be listed as @author
, unless specifically requested by the author. Similarly, if code refers to a specific publication, please include a formatted citation under @references
.
Exported functions. As mentioned above, the NAMESPACE is handled automatically by roxygen2
. Only functions required by users should be exported with @export
. For example, the sim_core
family of functions should NOT be exported, while the sim
family of functions is supposed to be.
DAISIE is sorted and collaborated on via GitHub, on this same repository. On which you can make a branch (with the permission of the maintainer Rampal, GitHub account name: @rsetienne), this will allow you to work on code without disturbing the existing working DAISIE (master
branch).
Once your code is working, it can be merged with the develop
branch and eventually master
. Code can be pushed to your branch using git, either through the command line or directly in RStudio. Do not merge your topic branch to develop
if your branch fails R CMD Check
. You can run R CMD Check
locally using RStudio with Ctrl
+ Shift
+ E
, on Windows you will need to have the latest version of RTools installed to build and check the package from source. Topic branches can only be merged to develop
, and only develop
is merged to master
.
The DAISIE package on GitHub uses continuous integration (CI) using Travis CI. This means that every time you push code to the GitHub repository it will be built, checked for errors and test coverage will be calculated and uploaded to codecov.io.
R CMD Check
will take too long and fail.Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.