# [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...