Closes #23: ADVS template program #35
Conversation
AndersAskeland
changed the title
|
|
Think it should be ready for review now. Feel free to review @pharmaverse/admiralmetabolic . I've used a somewhat different layout/setup compared to the other admiral packages. For me it makes more sense, but please let me know if it appears strange. |
There was a problem hiding this comment.
Thanks @AndersAskeland!
I did a quick review and left some initial comments - I haven't tired executing the template yet.
In general, I am wondering if we would benefit from building on the existing ADVS template from {admiral} (rather than starting afresh like here) and just adding our extra bits? It would make review easier as well. interested in your thoughts.
inst/ad_advs.R
Outdated
| advs <- advs |> | ||
| derive_vars_merged( | ||
| dataset_add = adsl, | ||
| new_vars = exprs(TRTSDT, TRTEDT, TRT01P, TRT01A), |
There was a problem hiding this comment.
exprs(TRTSDT, TRTEDT, TRT01P, TRT01A) should be stored as adsl_vars (see here) because you then re-use them on line 239 anyway.
There was a problem hiding this comment.
I actually disagree here. I personally believe that a template like this is often used nonsequential, where having arguments stored into objects can be confusing.
Furthermore, not having it stored in an object enables us to not use the injection operator (!!!) later in the code, which is in my opinion a fairly advanced feature which will confuse people.
There was a problem hiding this comment.
I see your point. I myself sometimes struggle with these operators myself!!
However:
- Within the {admiral} programming concepts and conventions sheet we specifically indicate that we use this style of quoting/unquoting, see here
- This is already used throughout all admiral templates so would be strange to vary within the extension package.
There was a problem hiding this comment.
I am still very hesitant about this change. I will implement it now, but I think it needs to be revisited in the future. I personally believe as Admiral becomes more widespread, we would need to lower the bar of entry. Especially considering many people coming in are coming from SAS with little to no experience in R.
Would also love the team (@pharmaverse/admiralmetabolic) to also give their input.
There was a problem hiding this comment.
Hi @AndersAskeland , I have posted some comments. Well done!
inst/ad_advs.R
Outdated
| library(stringr) | ||
|
|
||
|
|
||
| # Define look-up tables ---- |
There was a problem hiding this comment.
I would place link to the function directly before using the function
There was a problem hiding this comment.
What do you mean? Would you place the library calls directly before using any functionalities within that package? I.e. that we load stringr() right before the code where we actually use it?
There was a problem hiding this comment.
I would place "https://pharmaverse.github.io/admiral/reference/derive_vars_merged_lookup.html" link directly before using the function derive_vars_merged_lookup(), same with derive_vars_cat()
There was a problem hiding this comment.
The lookup table creations were moved a bit around, where they now reside under their respective use places. That actually means that the functions are not referenced directly. Instead the respective BDS vignette part is referenced, which should have some description about lookup tables. I think this is adequate, do you agree @starosto ?
There was a problem hiding this comment.
@AndersAskeland thanks for the update.
Please consider to add link to the function/BDS vignette part right before derive_vars_merged_lookup() function call.
|
@pharmaverse/admiralmetabolic If anyone have time, please have a review of the template. |
| # Define parameter look-up table used for merging parameter codes to ADVS | ||
| param_lookup <- tribble( | ||
| ~VSTESTCD, ~PARAMCD, ~PARAM, ~PARAMN, ~PARCAT1, ~PARCAT1N, | ||
| "HEIGHT", "HEIGHT", "Height (cm)", 1, "Anthropometric measurements", 1, |
There was a problem hiding this comment.
| "HEIGHT", "HEIGHT", "Height (cm)", 1, "Anthropometric measurements", 1, | |
| "HEIGHT", "HEIGHT", "Height (cm)", 1, "Anthropometric Measurement", 1, |
For consistency with the ADVS vignette
| # place | ||
| set_admiral_options(subject_keys = exprs(STUDYID, USUBJID)) | ||
|
|
||
| # Store ADSL join variables as an R object, enabling simplified usage throughout |
There was a problem hiding this comment.
| # Store ADSL join variables as an R object, enabling simplified usage throughout | |
| # Store ADSL variables required for derivations as an R object, enabling simplified usage throughout |
| vs_metabolic <- admiralmetabolic::vs_metabolic | ||
| adsl <- admiral::admiral_adsl | ||
|
|
||
| # Convert SAS empty values to NA |
There was a problem hiding this comment.
| # Convert SAS empty values to NA | |
| # Convert SAS missing character values values to NA |
| # Merge ADSL variables (stored in `adsl_vars`) needed for ADVS | ||
| # derivations |
There was a problem hiding this comment.
| # Merge ADSL variables (stored in `adsl_vars`) needed for ADVS | |
| # derivations | |
| # Derivations ---- | |
| # Merge ADSL variables (stored in `adsl_vars`) needed for ADVS |
| # Add parameter (PARAMCD) info to enable later ADVS derivations. Additional | ||
| # parameter information will be merged again, after all AVDS derivations are | ||
| # completed. |
There was a problem hiding this comment.
| # Add parameter (PARAMCD) info to enable later ADVS derivations. Additional | |
| # parameter information will be merged again, after all AVDS derivations are | |
| # completed. | |
| # Add parameter (PARAMCD) info to enable later ADVS derivations. Additional | |
| # parameter information will be merged again, after all AVDS derivations are | |
| # completed. | |
| # See function documentation for `derive_vars_merged_lookup()`: | |
| # (https://pharmaverse.github.io/admiral/reference/derive_vars_merged_lookup.html) |
| dataset_add = param_lookup, | ||
| new_vars = exprs(PARAMCD, PARAM, PARAMN, PARCAT1, PARCAT1N), |
There was a problem hiding this comment.
| dataset_add = param_lookup, | |
| new_vars = exprs(PARAMCD, PARAM, PARAMN, PARCAT1, PARCAT1N), | |
| dataset_add = select(param_lookup, -VSTESTCD), |
inst/ad_advs.R
Outdated
| library(stringr) | ||
|
|
||
|
|
||
| # Define look-up tables ---- |
There was a problem hiding this comment.
@AndersAskeland thanks for the update.
Please consider to add link to the function/BDS vignette part right before derive_vars_merged_lookup() function call.
There was a problem hiding this comment.
@AndersAskeland I added some comments. I also wonder if we should not build on existing ADVS templates from {admiral}. If not now, then for future templates.
| # Define project options/variables ---- | ||
| # Use the admiral option functionality to store subject key variables in one | ||
| # place | ||
| set_admiral_options(subject_keys = exprs(STUDYID, USUBJID)) |
There was a problem hiding this comment.
| set_admiral_options(subject_keys = exprs(STUDYID, USUBJID)) |
subject_keys defaults to exprs(STUDYID, USUBJID), we don't need to set this up
There was a problem hiding this comment.
LGTM @AndersAskeland 😄 (after comments from @starosto are addressd)
Closes #23
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 family 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
mainbranch until you have checked off each task.styler::style_file()to style R and Rmd filesdevtools::document()so all.Rdfiles in themanfolder and theNAMESPACEfile in the project root are updated appropriatelyNEWS.mdunder the header# admiral<ext> (development version)if the changes pertain to a user-facing function (i.e. it has an@exporttag) or documentation aimed at users (rather than developers)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 checklocally and address all errors and warnings -devtools::check()