8 Conclusion

openstatsware Course: Good Software Engineering Practice for R Packages

Daniel

September 26, 2023

Temperature check

Enter menti.com: 5748 1949

Take away messages

R package structure

  • R package = folder structure with (many) conventions
  • With modern tools usethis, roxygen2 it is easy to start a new package
  • Packaging a set of functions is an ideal way to share with collaborators and the public
  • Start small and simple and over time you can learn additional options

Engineering Workflow

  • Use a workable workflow:
    Idea \(\rightarrow\) Design docs \(\rightarrow\) Programming \(\rightarrow\) Quality check \(\rightarrow\) Publication
    • Don’t waste time on maintenance
    • Be faster with release on CRAN
    • Fulfill regulatory requirements
  • Refactor your one-off scripts that you want to use in a package
  • Use assertions for all arguments \(\rightarrow\) Usability/UX
  • Implement common generics like print and plot

Ensuring Quality

  • Apply common clean code rules, e.g.,
    • Use testthat to test, test, and test
    • Use covr to improve the test coverage
    • Use styler to optimize the code styling
    • Don’t repeat yourself!
  • Your rewards are:
    • Maintainability,
    • Extensibility, and
    • Performance!

Collaboration

  • Version control is key
    • Multiple people working on code without strong VC \(\leadsto\) disaster!
    • There are different options, but git is the defacto standard for R packages
    • Git needs a friend - use platforms like GitHub or GitLab
  • Automated CI/CD allows for much quicker iteration
    • Automate tests to avoid bugs slipping back in
  • Technology does not solve everything - foster a positive culture
    • Keep internal and external contributors engaged
    • Invest in documentation to make it easier to contribute

Publication

  • pkgdown can help you easily create a nice website for your package
  • Versions and licenses along with NEWS updates are important
  • GitHub helps with tagging of release versions
  • R-Hub helps with checking before CRAN submission

Shiny

  • Best practices are not just important for R packages, also for Shiny!
  • Design UI and package structure first, minimize actual Shiny code
  • Shiny modules help to make the reactivity manageable
  • Use normal tests for static code, server tests and shinytest2 for Shiny code

Closing remarks

Thank you!

  • It was great to teach you today on how to build R packages
  • Let’s keep in touch e.g. via gitter chat channel or wechat channel for this course that you can connect to
  • We welcome feedback on topics/format/content - reach out!

Possible next steps

  • Bring the information back to your colleagues in your organization
  • Start building your first own package and share internally first
  • Later publish it open source on GitHub and submit it to CRAN
  • Learn about more tips and tricks how to extend R

License information

Good Software Engineering Practice for R Packages - Home | Slides | License