In BioPharmSoftGrp/BaSS: PREP - Packages fRom tEmPlates

Introduction

This project is organized as a R package and all code is in the R directory and test code in tests/testthat.

All of the usual package development can be followed. For example, to build the package click on Build->Clean and Rebuild. This is also available Build tab typically to right pane in R Studio. Once the package is built and installed, you can use it like any other package.

If you are new to building R packages you may find the R Packages Book very helpful.

In addition, to help improve testing and stability of the application, the application is developed using Shiny modules. You may find introduction to Shiny modules helpful and Chapter 15 of Mastering Shiny by Hadley Wickham is also very helpful.

Helpful PREP Commands

Now that you have setup your new PREP Package you may find the following commands helpful:

#. PREP::AddFunctionToPkg #. PREP::AddTab - For PREP Shiny Application #. PREP::AddModules - For PREP Shiny Application #. PREP::AddModule - For PREP Shiny Application

Example: AddFunctionToPkg( strFunctionName, strFunctionDescription = "", strPkgDir = "" ) - Add a new function named strFunctionName to a package. This function creates a file names R/strFunctionName.R and adds a test function in the file tests/testthat/test-strFunctionName.R to be used with the testthat package.

Helpful packages

#. PREP - This packages was used to setup the GoNGCalcs and GoNGShiny projects. It can be installed with remotes::install_github("BioPharmSoftGrp/PREP") #. covr - Use to create a test coverage report with the following commands #. testthat - Package used for creating tests for your package.

Helpful Code and Code Snippets

From the PREP package, AddFunctionToPkg( strFunctionName, strPkgDir = "", strFunctionDescription = "" ) - Add a new function named strFunctionName to a package. This function creates a file names R/strFunctionName.R and adds a test function in the file tests/testthat/test-strFunctionName.R to be used with the testthat package.

To execute all tests in the project, execute the following code

#' @export
devtools::test()

Code snippets are very useful within R Studio. They allow you to type a short phrase and automatically insert a block of code.

Add code snippet by Clicking Tools-> Global Options -> Code-> Edit Snippets

```r snippet news3meth #' @name ${1} #' @title ${1} #' @description ${4:function description} #' @export ${1:MethodName} <- function( ${2:ClassObjName} ) { UseMethod( "${1}", ${2} ) } ${1}.default <- function( ${2} ) { stop( "The default method for ${1} is not defined.") }

snippet newcom r paste( paste( rep( "#", 100), collapse="" ), "." ) # ${0} #### r paste( paste( rep( "#", 100), collapse="" ), "." )

snippet header r paste( paste( rep( "#", 100), collapse="" ), "." ) # Program Name: ${1} # Author: J. Kyle Wathen # Description: # Category: # Usage: # Change History: r paste( paste( rep( "#", 100), collapse="" ), "." ) ```

Helpful Links

1. S3 Classes
2. R Packages Book
3. Mastering Shiny a. Introduction to Shiny modules b. Chapter 15 - Scaling Shiny Modules
4. Testing a. Testing R with testthat b. From R packages
5. Git Source Control
   a. Getting Started with Version Control b. Git for Windows c. Tortoise Git - Free Window shell program (runs in Windows explorer by Right clicking on a folder/file)]
6. R Studio Cheatsheet - There are several really good ones but the R Markdown, R Studio IDE and Shiny cheatsheets are really helpful for this project.

Style Guide

It is recommended to follow a style guide. One potential guide to use is the Biopharm Soft style guide. When developing code so that the style is consistent across different developers. A few key highlights are provided below.

If you are using source control such as GitHub it can be helpful to have guidelines. Please refer to the GitHub Section of the style guide when naming branches.

GitHub and Version Numbers

The section outlines the approach and rational for GitHub and the version numbers.

GitHub

Everyone creates feature/bug/documentation branches off of Dev.
Using IT to represent the users initials, branch names should follow a consistent naming pattern, like Feature-Add-XXX-IT, Test-CalcCHM-IT, Bug-XXX-IT. For example of Bob Smith (BS) was creating a branch to add a feature two add two numbers a good branch name would be Feature-Add2Numbers-BS.

Pull Requests (PRs) are against Dev so that when the are merged the issues close automatically. Then when a release is ready, eg whatever updates are going to be included have been merged into Dev, a PR is filled for Dev to be merged to master.

Branches are intended to be small and something a developer adds specific items to, then merges via a PR. A branch should be work that can be completed in a few hours/days and not weeks.

Once a PR for Dev->Master is executed, please make sure Dev and Master are at the same point. One way this can be done on GitHub by going to the Insights tab then clicking on Network.

A few details about the setup on GitHub:

@. A Dev branch has been created and set as the default. @. The option to "Automatically delete branches" when a PR is merged, is enabled. With this option enabled, when a PR is merged to Dev, the "from" branch is automatically deleted. By automatically deleting branches when a PR is merged, the remote repo (eg GitHub) should have fewer branches and be more clean. The auto delete feature does allow us to restore a delete branch if we need to. @. Since Dev is the default it will NOT be deleted when a PR from Dev->Master occurs.

Please note, the branch is ONLY deleted on the remote repo and is NOT deleted in the local repo. So if you were working on a branch Feature-123 and you file a PR from Feature-123 -> Dev when the PR is merged the Feature-123 branch is deleted on the remote, eg GitHub, but you still have a local copy on your computer. There are a few ways to delete a local branch.

Version Numbering

We will use the version numbers from semver.org

The following is the general version number explanation Version numbering from Sematic

• 0.0.x doesn't add features (mostly for bug fixes and documentation)
• 0.x.0 adds new features, but doesn't effect backwards compatibility.
• x.0.0 breaks backwards compatibility in some way.

Rationel for GitHub/Version Numbers

A few advantages of this approach:

• The version number is easy to explain and understand.
• The master branch is always the release
• When someone needs to create a branch it always come off of Dev (for all projects) and issues get closed when merge to Dev occur.
• Version numbers can quickly be explained.

This avoids us having to ask or remember what Dev-VX.X.X to create a branch off of or what issues have been closed when we have multiple people in different places working on things.

BioPharmSoftGrp/BaSS documentation built on April 2, 2021, 2:34 a.m.