Closes #23: ADVS template program

[AndersAskeland]

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.

• Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• Code is formatted according to the tidyverse style guide. Run styler::style_file() to style R and Rmd files
• Updated relevant unit tests or have written new unit tests, which should consider realistic data scenarios and edge cases, e.g. empty datasets, errors, boundary cases etc. - See Unit Test Guide
• If you removed/replaced any function and/or function parameters, did you fully follow the deprecation guidance?
• Update to all relevant roxygen headers and examples, including keywords and families. Refer to the categorization of functions to tag appropriate keyword/family.
• Run devtools::document() so all .Rd files in the man folder and the NAMESPACE file in the project root are updated appropriately
• Address any updates needed for vignettes and/or templates
• Update NEWS.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)
• Build site pkgdown::build_site() and check that all affected examples are displayed correctly and that all new functions occur on the Reference page.
• Address or fix all lintr warnings and errors - lintr::lint_package()
• Run R CMD check locally and address all errors and warnings - devtools::check()
• Link the issue in the Development Section on the right hand side.
• Address all merge conflicts and resolve appropriately
• Pat yourself on the back for a job well done! Much love to your accomplishment!

[github-actions]

Package	Line Rate	Health
admiralmetabolic	100%	✔
Summary	100% (3 / 3)	✔

[AndersAskeland]

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.

[manciniedoardo]

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.

[manciniedoardo]

exprs(TRTSDT, TRTEDT, TRT01P, TRT01A) should be stored as adsl_vars (see here) because you then re-use them on line 239 anyway.

[AndersAskeland]

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.

[manciniedoardo]

I see your point. I myself sometimes struggle with these operators myself!!

However:

1. Within the {admiral} programming concepts and conventions sheet we specifically indicate that we use this style of quoting/unquoting, see here
2. This is already used throughout all admiral templates so would be strange to vary within the extension package.

[AndersAskeland]

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.

[manciniedoardo]

is this required?

[AndersAskeland]

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 ?

[Siddhesh2097]

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

[starosto]

Hi @AndersAskeland , I have posted some comments. Well done!

[starosto]

I would place link to the function directly before using the function

[AndersAskeland]

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?

[starosto]

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()

[AndersAskeland]

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?