-
Notifications
You must be signed in to change notification settings - Fork 314
Contributing
-
Use 8-width tabs. A level 4 indent is 4 spaces, level 8 is 1 tab, level 12 is 1 tab + 4 spaces, etc.
-
Use
/* */
comments in C code, even for single-line comments. Use double##
in R code. -
Use
nprot
to count the number of protected variables.
-
tests/reg-tests-1d.R
is the current general purpose test file, for R >= 3.4.0. -
Use one solid paragraph (no newlines) per test. The paragraph should start and end with comments.
-
If you change the session's state in your test (set options, create variables), restore the original state at the end.
-
Some test files save the console output to a .Rout file that is compared to a .Rout.save. If you add a test or somehow change the output, update the .Rout.save file and commit it.
See tests/README
.
-
Note that for complete testing you will need a number of other packages installed and available, so if you have a CRAN installation, set R_LIBS (perhaps in ~/.R/check.Renviron) to include it before running these tests. For example, some of the tests on 'nlme' depend on 'Hmisc', and there are a number of cross references from help pages to CRAN packages.
-
Set the
TEST_MC_CORES
environment variables to run tests in parallel.
The simplest way is to create them from git commits or git branches. Send a pull request or branch to your github's mirror repo and append .patch
to a PR or commit URL. In case of a branch, all commits are folded in a single patch.
To do this manually, use git format-patch
. When given one argument (a revision), it creates patches for each commit from that revision to the current head:
git checkout mypatch
git format-patch trunk
Squash the commits together beforehand if you'd like to create a single patch.
If the patch is trivial (fixes a bug, implements a small feature that was already discussed), create a bugzilla report with a reprex if there isn't one already. Attach the patch, click on "Show Advanced Fields" to reveal the "Content Type" checkbox and declare the attachment is a patch. This way the patch is properly formatted in the bug report.
If the patch introduces a new feature or change the API, it's probably better to discuss it first on r-devel or with the relevant R core maintainer.