Cover and modify, some tips for R package development
I’ve recently been dealing with legacy code refactoring both in theory and in practice: while I’m continuing some work on the igraph R package, I’ve started reading Working Effectively with Legacy Code by Michael Feathers, that had been in my to-read pile for months. In this post, I’ll summarize some ideas from both the book and my work. “Cover and modify” with “characterization tests” When you start modifying your rusty code, how do you ensure you do not break existing and important behaviour inadvertently?
Create and use a custom roxygen2 tag
This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. You might know that it’s possible to extend roxygen2 to do all sorts of cool things including but not limited to: documenting your internal functions for developers only (that’s devtag by my cynkra colleague Antoine Fabri), recording your following statistical software standards (that’s srr by my rOpenSci colleague Mark Padgham), writing tests from within R scripts (that’s roxytest by Mikkel Meyer Andersen).
Does my test really validate a bug fix? Check it with git cherry-pick
Earlier this year I wrote a post about git worktree that allows you to load different versions of an R package at once on your computer. To keep with the “juggle between versions of a codebase with Git plant-related commands” theme, let me show you how I use cherry-pick to assess the quality of an unit test. Scenario: you fix a bug in a branch In a perfect world, the bug you’re working on is paired with a ✨ reprex ✨, and you even start your work by adding a test case for it.
Get your codebase lint-free forever with lintr
This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. Writing good code is hard. Some aspects get easier with experience – although I observe that I consistently forget some things. 🙈 Other aspects can be tackled through code review – although your reviewer’s time will be better spent on design questions than on nitpicks. 💅 Static code analysis can help with code quality.
Extracting names of functions defined in a script with treesitter
Coming back from a conference, we might be excited to install and try out the cool things we have heard about. I, going against the stream 🐟, decided to experiment with a tool I have not heard about last week, as I unfortunately missed Davis Vaughan’s talk about treesitter. Nonetheless, I caught the idea that treesitter is a parser of code, R code in particular. The treesitter R package uses the tree-sitter C library.