R package development
Key commands
# Run code in the package
Rscript -e "devtools::load_all(); code"
# Run all tests
Rscript -e "devtools::test()"
# Run all tests for files starting with {name}
Rscript -e "devtools::test(filter = '^{name}')"
# Run all tests for R/{name}.R
Rscript -e "devtools::test_active_file('R/{name}.R')"
# Run a single test "blah" for R/{name}.R
Rscript -e "devtools::test_active_file('R/{name}.R', desc = 'blah')"
# Redocument the package
Rscript -e "devtools::document()"
# Check pkgdown documentation
Rscript -e "pkgdown::check_pkgdown()"
# Check the package with R CMD check
Rscript -e "devtools::check()"
# Format code
air format .
Coding
- Always run
air format. after generating code. - Use the base pipe operator (
|>) not the magrittr pipe (%>). - Use
\()... for single-line anonymous functions. For all other cases, use function() {...}.
Testing
- Tests for
R/{name}.R go in tests/testthat/test-{name}.R. - All new code should have an accompanying test.
- If there are existing tests, place new tests next to similar existing tests.
- Strive to keep tests minimal with few comments.
- Avoid
expect_true() and expect_false() in favour of a specific expectation which will give a better failure message. - When testing errors and warnings, don't use
expect_error() or expect_warning(). Instead, use expect_snapshot(error = TRUE) for errors and expect_snapshot() for warnings because these allow the user to review the full text of the output.
Documentation
- Every user-facing function should be exported and have roxygen2 documentation.
- Wrap roxygen comments at 80 characters.
- Internal functions should not have roxygen documentation.
- Whenever you add a new (non-internal) documentation topic, also add the topic to
_pkgdown.yml. - Always re-document the package after changing a roxygen2 comment.
- Use
pkgdown::check_pkgdown() to check that all topics are included in the reference index.
NEWS.md
- Every user-facing change should be given a bullet in
NEWS.md. Do not add bullets for small documentation changes or internal refactorings. - Each bullet should briefly describe the change to the end user and mention the related issue in parentheses.
- A bullet can consist of multiple sentences but should not contain any new lines (i.e. DO NOT line wrap).
- If the change is related to a function, put the name of the function early in the bullet.
- Order bullets alphabetically by function name. Put all bullets that don't mention function names at the beginning.
