-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closes #23: ADVS template program #35
base: main
Are you sure you want to change the base?
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
inst/ad_advs.R
Outdated
), | ||
get_unit_expr = VSSTRESU, | ||
filter = VSSTAT != "NOT DONE" | is.na(VSSTAT), | ||
constant_by_vars = exprs(USUBJID) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which part? I am unsure about the filter, but it is based on our current vignette. Do you know why we have used a filter @Siddhesh2097 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is as per the BDS finding vignette. But it's not required in this case as per the vs_metabolic data.
I think we should remove it as it creates unnecessary confusion to the user.
@AndersAskeland @manciniedoardo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would place link to the function directly before using the function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
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
main
branch until you have checked off each task.styler::style_file()
to style R and Rmd filesdevtools::document()
so all.Rd
files in theman
folder and theNAMESPACE
file in the project root are updated appropriatelyNEWS.md
under the header# admiral<ext> (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)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()