closes #2805 add template for ADAB

[Kcdahn]

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.

• [x] Place Closes #<insert_issue_number> into the beginning of your Pull Request Title (Use Edit button in top-right if you need to update)
• [x] 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?
• [ ] Review the Cheat Sheet. Make any required updates to it by editing the file inst/cheatsheet/admiral_cheatsheet.pptx and re-upload a PDF and a PNG version of it to the same folder. (The PNG version can be created by taking a screenshot of the PDF version.)
• [ ] 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 (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 in NEWS.md for tracking developer-facing issues.
• [ ] Build admiral 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!

[bms63]

can you also fix all the failing actions please

[github-actions[bot]]

Package	Line Rate	Health
admiral	100%	✔
Summary	100% (5738 / 5751)	✔

[Kcdahn]

@Fanny-Gautier Hi. Thanks for the general and code segment comments. I pushed a version with catch all TRUE adds a few weeks ago. My next draft is working on the keeping lines under 100, expanding case_when() or converting them to if_else(). Couple questions/comments on the if_else(). I ran into a situation where a couple converted if_else()'s did not work. I did a search and my interpretation of it was if the left side is missing all possibilities, the else might not apply the value (when its not na_*). The solution was to use case_when(). I did find several I could convert to if_else() but wonder if I can leave some. I have used a comparable version of this template several times live before and feel more comfortable using certain case_when() even if only two elements (in case there are new values or the user tweaks to the upstream code that feeds into them adds more evaluable values) . I also find them easier to read in certain blocks of code. Lastly, since its a template for users to tweak for their local study needs, I suspect many of the 2 part case_when()'s could potentially need expansion when adapted for live studies. I do have a new update almost ready to push addressing these and other comments. I can push that when ready, reply to code segment comments and then you can consider all this? Thanks!

[Fanny-Gautier]

@Fanny-Gautier Hi. Thanks for the general and code segment comments. I pushed a version with catch all TRUE adds a few weeks ago. My next draft is working on the keeping lines under 100, expanding case_when() or converting them to if_else(). Couple questions/comments on the if_else(). I ran into a situation where a couple converted if_else()'s did not work. I did a search and my interpretation of it was if the left side is missing all possibilities, the else might not apply the value (when its not na_*). The solution was to use case_when(). I did find several I could convert to if_else() but wonder if I can leave some. I have used a comparable version of this template several times live before and feel more comfortable using certain case_when() even if only two elements (in case there are new values or the user tweaks to the upstream code that feeds into them adds more evaluable values) . I also find them easier to read in certain blocks of code. Lastly, since its a template for users to tweak for their local study needs, I suspect many of the 2 part case_when()'s could potentially need expansion when adapted for live studies. I do have a new update almost ready to push addressing these and other comments. I can push that when ready, reply to code segment comments and then you can consider all this? Thanks!

ok, thank you for the clarification and it is fine to keep the case_when() when it is easier and giving the right results. if_else()use is only a recommendation.

[Kcdahn]

@Kcdahn could we do the vignette in a separate Pull Request? This one has already gotten pretty busy and nice to start with a fresh PR.

OK, Removed and added the initial draft vignette to that new branch.

[manciniedoardo]

@Kcdahn please could you resolve all threads which have been actioned?