Skip to content

Software development

The 5 Do's of software package development

Author: Tom Palmer

The following are meant as a set of guidelines for you to consider adopting in your software development practices. We don't expect people to adopt all of these points instantly. Perhaps try adopting one point at a time. We ask that the more popular your software becomes the more of these points you consider adopting.

  • Do document code in a way standard for chosen language
    • If coding an R package consider using roxygen syntax to generate the helpfiles
    • If your R package is compliant with R CMD check then running pkgdown::build_site() will generate a website for your package which you can host for free using GitHub Pages or Netlify
  • Do use existing best practices guidance for developing package
    • If coding an R package try and follow CRAN policies as much as possible
    • As a minimum please run R CMD check / devtools::check() on your package and ensure your code returns 0 check errors
    • You can run R CMD check as a GitHub Action, for an example see here
    • If submitting to CRAN/Bioconductor you will additionally require 0 check warnings, and it's even better to also return 0 check notes
  • Do get code reviewed by a friendly colleague internally
    • You can either do this informally or by requesting a review on a pull request on GitHub
    • Having a video call with your reviewer to talk them through your changes/PR can help
    • If this is going to be a heavily used package consider turning on branch protection to the main branch on GitHub with a requirement of say at least 1 approved review for every pull request
  • Do test your code and incorporate tests in packages
    • If coding an R package consider integrating tests using frameworks such as testthat or tinytest. If coding a Python package consider using pytest.
  • Do maintain your code overtime
    • R and Python and other software are updated with new features regularly. If coding a package remember to test your package on the new versions as (or before release using the development versions) they are released.
    • Dependency packages may be updated which can also cause you to need to update your package
    • You can set up automated GitHub Actions workflows with scheduled cron jobs to assist with checking this. For an example see here

Monthly meetings

Leads: Yi Liu and Tom Palmer

We'll hold meetings in OS6 at Oakfield House every 2nd Tuesday of the month at 12pm. Lunch will be provided! Sessions are themed and will be recorded.

List of meetings...