checklist.md
In moj-analytical-services/PQTool: Parliamentary Questions Tool
|Activity|Done (delete as appropriate)| Notes |
|---|---|---|
|Code Structure|||
|Clear logical separation of parameters, assumptions, data, and code. For R, use this, and use Hadley’s Style Guide|✅||
|Your code should (but not must) pass the relevant linter|❌||
|Appropriate use of abstractions like functions, packages, modules etc, which has been reviewed by language expert. For R, you should use packages as fundamental units of code.|✅||
|If using a notebook (e.g. an R or Jupyter notebook) for your write up, functions are factored out to maintain narrative. For R, factor out code either into a source()ed .R file or a package|✅||
|Reproducibility|||
|If the output is a report, the write up is fully reproducible, or as close as possible. For R, use rmarkdown|✅||
|Development workflow|||
|Code is version controlled using Git and checked into Github You can find a guide to using Git with R here|✅||
|The project is developed using Git flow. |✅||
|All code has been subject to code review. This process has been managed through pull requests, and this evidenced in Github. This should typically involve the reviewer pulling the code to their local machine, testing it, and leaving comments in the pull request. |✅||
|Documentation|||
|You have added a description to your Github repository and tagged it with appropriate tags|✅||
|A README.md file exists in the repository, which contains standard fields |✅||
|Code is appropriately commented. Comments are for explaining why something is needed, not how it works.|✅||
|All non trivial functions are documented using the programming language's accepted standard. For R, use roxygen2 to document your functions.|✅||
|Unit testing|||
|Unit tests exist that test the overall codebase, but not individual functions. In R, you should use the testthat package for unit testing. You can find examples of how to do unit testing here and here|✅||
|Unit tests exist at the function level, which test a range of parameters. |✅||
|Your unit testing has reached code coverage of at least 75%|✅||
|Dependency Management|||
|You dependencies are explicitly managed. For R, use packrat|✅||
|Packages and versions|||
|You have used the sensible defaults, unless you have a good reason not to and have agreed this with your line manager|✅||
|Language specific|||
|Code Style: You must follow Hadley’s style guide|✅||
|In R, you should generally use a functional programming style.|✅||
moj-analytical-services/PQTool documentation built on June 12, 2021, 5:31 a.m.
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
|Activity|Done (delete as appropriate)| Notes |
|---|---|---|
|Code Structure|||
|Clear logical separation of parameters, assumptions, data, and code. For R, use this, and use Hadley’s Style Guide|✅||
|Your code should (but not must) pass the relevant linter|❌||
|Appropriate use of abstractions like functions, packages, modules etc, which has been reviewed by language expert. For R, you should use packages as fundamental units of code.|✅||
|If using a notebook (e.g. an R or Jupyter notebook) for your write up, functions are factored out to maintain narrative. For R, factor out code either into a source()ed .R file or a package|✅||
|Reproducibility|||
|If the output is a report, the write up is fully reproducible, or as close as possible. For R, use rmarkdown|✅||
|Development workflow|||
|Code is version controlled using Git and checked into Github You can find a guide to using Git with R here|✅||
|The project is developed using Git flow. |✅||
|All code has been subject to code review. This process has been managed through pull requests, and this evidenced in Github. This should typically involve the reviewer pulling the code to their local machine, testing it, and leaving comments in the pull request. |✅||
|Documentation|||
|You have added a description to your Github repository and tagged it with appropriate tags|✅||
|A README.md file exists in the repository, which contains standard fields |✅||
|Code is appropriately commented. Comments are for explaining why something is needed, not how it works.|✅||
|All non trivial functions are documented using the programming language's accepted standard. For R, use roxygen2 to document your functions.|✅||
|Unit testing|||
|Unit tests exist that test the overall codebase, but not individual functions. In R, you should use the testthat package for unit testing. You can find examples of how to do unit testing here and here|✅||
|Unit tests exist at the function level, which test a range of parameters. |✅||
|Your unit testing has reached code coverage of at least 75%|✅||
|Dependency Management|||
|You dependencies are explicitly managed. For R, use packrat|✅||
|Packages and versions|||
|You have used the sensible defaults, unless you have a good reason not to and have agreed this with your line manager|✅||
|Language specific|||
|Code Style: You must follow Hadley’s style guide|✅||
|In R, you should generally use a functional programming style.|✅||
R Package Documentation
Browse R Packages
We want your feedback!
Note that we can't provide technical support on individual packages. You should contact the package authors for that.
Embedding an R snippet on your website
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.