# [srr](https://github.com/ropenscilabs/srr) ### Motivation: Colin Gillespie, [European R Users Meeting 2020](https://2020.erum.io/program/keynotes-invited-speakers/): > Standards are good > Standards should be strict > No-one reads standards ... to which I would add: > Nobody adheres to standards unless you place them right in front of them and force them to do something about it. ### Context: Context for the package, in terms of the four essential tasks of coding: 1. Save 2. Document 3. Check 4. Commit - Building a system to respond to (1) would be entirely possible, but platform-dependent, and likely annoying to use. - (2) is mostly where `rssr` does its stuff - (3) is not worth addressing because `R CMD check` takes too long - (4) Is entirely possible via pre-commit hooks, and would be a viable alternative to current implementation. ## Questions: 1. Is `roxygen` the best way to do this? Are alternatives worth investigating? 2. Is it at all sensible to have `roxygen` tags define parameters to be parsed by the roclets? Are there any dangers in doing that? 3. Are the three tags sufficient (`@rssr`, `@rssrNA`, `@rssrTODO`)? 4. Identificaton of standards is currently mostly `grep`-based. Would it be better/safer to insist standard numbers always directly follow `roxygen` tags, rather than current system that allows them anywhere after a tag? 5. I allow `NULL` blocks in `./R` files, but presume all blocks in `src/` files are associated with functions. Is this sensible / likely to go wrong? 6. Parsing of `src` code currently restricted to `.c`, `.h`, `.cpp`, `.hpp`. Should this be expanded? ## Still to do: 1. Add an extra `rssrVersion` tag to document standards version, and error if this tag not found. 2. Write a "pre-submission" function which does a fresh download of standards and ensures that every standard is addressed somewhere in the code. 3. Parse tags which have ranges of standards (like `G1.0-1.3`). 4. Extend parsing `src` tags to `inst` directory too. 5. Refine the `@rssrVerbose` tag to allow selective finer control over output. ## Questions/Comments Feedback Noam: - How do we handle the case where one standard applies in multiple locations within the code? - Can we tag within vignettes, README, CONTRIBUTING.md, or other non-R files, as many standards refer to these types of documentation - How do we get the data structure with the parsed data that we can use/manipulate? - How about having the summary output written to something like `inst/rssr-standards.md` so that you can see the level of compliance by browsing the repository. - Idea for the future - can we port the dev guide standards to this format? - Perhaps `rstd` so this is a general standards package and one can just point to a URL for any arbitrary standards set that somebody creates? (er, maybe STD is not the acronym we want...). `rosr` maybe...