Maëlle's R blog

Showcase of my (mostly R) work/fun

How to open files, folders, websites in R

Coming to you from France, a post about Mise en place for R projects. In a less francophone phrasing: to get to work on something you have to open that thing, be it a script or a project or a website. The easier that is, the faster you get to work. In this post I’ll show a roundup of R functions and related tools for opening scripts, projects and websites for yourself or on behalf of the users of your code.

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.