DEVELOPMENT GUIDE!

[khufkens]

These are notes on how to develop additions and what requirements need to be met to submit a new code addition. This will be a developing document pinned to the top of the issues list for your consultation.

Before you start

• UPDATE YOUR REPO (git fetch / pull)
  • Never work of a stale fork or branch
  • if you don't update and you push stale old code with your changes the pull request will not show this clearly and it will UNDO other people's work. Keep up to date with the main branch. So, push the FETCH UPSTREAM button if you don't fork anew.

• file an issue for every major change you plan to implement (this excludes documentation and unit tests - but is welcome regardless)

Code / Function style guide

• code no wider than 80 characters
• document all functions properly on writing / submission to the repo
  • use roxygen
  • ALWAYS wrap examples in \dontrun{}
• write unit tests for your function upon writing of the function
• do not use Vignettes as unit tests, these are for documentation NOT testing
• avoid tidyverse in functions where possible
  • if using tidyverse DECLARE YOUR VARIABLES at the start of the function, otherwise this will give a large list of notes you will need to resolve
• ...

Pull request submission checks

• run R CMD check on the command line or "check" in the build tab of RStudio
• there should never be Errors / Warnings
  • exceptions for warnings on 'ingestr': number of dependencies / size of the package
• ...

[lypluo]

so when we do the unit tests, should we create an unit test folder or where we should put the them?

[khufkens]

This folder already exists and tests follow the {testthat} logic.

https://github.com/computationales/ingestr/tree/master/tests/testthat

{testthat}
https://testthat.r-lib.org/

[khufkens]

Notes on commenting and header:

#41