Check List For R package dev from CV

[kdorheim]

Based on a slack conversation with @crvernon here is a check list (until a more official list or template is distributed) for R package development guidelines.

• [ ] we want to be able to access for the purpose of modification or distribution (get/set) key variables per time step
• [ ] we want to take a test driven approach where we have high and meaningful coverage the repo should be linked either to GitHub Actions (which I am looking more into) or right now through Travis-CI and Codecov (see the Python template here: https://github.com/IMMM-SFA/im3py
• [x] Let me know when you have the repo up and I'll also link to Zenodo. We want to have meaningful and timely releases from beta versions up with the semantic minimum of major.minor.bug-fix where a lower case "v" precedes the version number (e.g., v0.1.0)
• [ ] Each R software should use Doxygen style function docstring (like you do already)
• [ ] We want to develop our software as packages that can be distributed and direct any fundamental development to our core software (e.g., rgcam, rgis, etc.)
• [x] The README should include a getting started section that shows how to install, a run setup section if necessary, and an few examples.
• [x] all lowercase package names with no spaces or separators function and local variable names in lower case separated by underscores; meaningful names
• [ ] constants in all CAPS underscore separated stored in a separate file
• [x] use data.table instead of tidyverse. These can still be combined with pipes from magrittr . They are so much more efficient and readable
• [ ] Only small subsets of data for tests if needed; we do not want a large GitHub repository overhead. We will use the 'install_supplement' function I have built to fetch required inputs from a remote archive that we have minted a DOI for that matches the version of the software.
• [x] no use of GitLFS
• [ ] add the covde coverage that gives us a percent because that is cool but more importantly a better diagnostic

[kdorheim]

• [ ] A citation of the data itself (where you got it, when, version, etc.); if this data is used directly without modification in the code, then you are all good with that
• [ ] If it has been modified to create your inputs outside of the package, we need to know how and have the code that you used to do so.

[bpbond]

use data.table instead of tidyverse. These can still be combined with pipes from magrittr . They are so much more efficient and readable

It's too bad, but I don't find myself arguing this.

[crvernon]

use data.table instead of tidyverse. These can still be combined with pipes from magrittr . They are so much more efficient and readable

It's too bad, but I don't find myself arguing this.

I should have stated that some packages within the tidyverse may still be the best option. We should all set up a reasonable strategy for this.