Closed jeffreyad closed 3 months ago
Package | Line Rate | Health |
---|---|---|
admiral | 97% | ✔ |
Summary | 97% (4685 / 4813) | ✔ |
I think we have 2 other possible solutions for storing the country codes:
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie. dataset_add = get_country_codes()
.data
folder with r script that creates it stored in a sub-folder of inst
(data.R would need updated also).I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
I think we have 2 other possible solutions for storing the country codes:
- Have a function called
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie.dataset_add = get_country_codes()
.- We store the dataset in
data
folder with r script that creates it stored in a sub-folder ofinst
(data.R would need updated also).I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
Usually, datasets are stored in data
and the scripts which create them should be stored in data-raw
. Unfortunately, we are not following this convention. I would discuss it at the next meeting.
I think we have 2 other possible solutions for storing the country codes:
- Have a function called
get_country_codes
with the tibble inside it, then user can define the name of the dataset or call the function directly ie.dataset_add = get_country_codes()
.- We store the dataset in
data
folder with r script that creates it stored in a sub-folder ofinst
(data.R would need updated also).I don't think we have any other scripts that creates a dataset directly, like this does. So would be good to be consistent how we create what is essentially metadata?
Thanks @millerg23 and @bundfussr, I noticed dose_freq_lookup
in create_single_dose_dataset()
creates a tibble in this way. But I agree they should be consistent.
Thank you for your Pull Request! We have developed this task checklist from the Development Process Guide to help with the final steps of the process. Completing the below tasks helps to ensure our reviewers can maximize their time on your code as well as making sure the admiral codebase remains robust and consistent.
Please check off each taskbox as an acknowledgment that you completed the task or check off that it is not relevant to your Pull Request. This checklist is part of the Github Action workflows and the Pull Request will not be merged into the
main
branch until you have checked off each task.styler::style_file()
to style R and Rmd filesinst/cheatsheet/admiral_cheatsheet.pptx
and re-upload a PDF version of it to the same folder.devtools::document()
so all.Rd
files in theman
folder and theNAMESPACE
file in the project root are updated appropriatelyNEWS.md
under the header# admiral (development version)
if the changes pertain to a user-facing function (i.e. it has an@export
tag) or documentation aimed at users (rather than developers). A Developer Notes section is available inNEWS.md
for tracking developer-facing issues.pkgdown::build_site()
and check that all affected examples are displayed correctly and that all new functions occur on the "Reference" page.lintr::lint_package()
R CMD check
locally and address all errors and warnings -devtools::check()