good practice

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.

I’ve now explained on this blog why it’s important to have small, informative Git commits1 and how I’ve realized that polishing history can happen in a second phase of work in a branch. However, I’ve more or less glossed over how to craft the history in a branch once you’re done with the work. I’ve entitled this post “Hack your way to a good Git history” because writing the history after the fact can feel like cheating, but it’s not!

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. “Make small Git commits with informative messages” is a piece of advice we hear a lot when learning Git. That’s why we might want to sometimes rewrite history in a branch. In this post, I’d like to underline three main (😉) reasons why you’ll be happy you, or someone else, made small and informative Git commits in a codebase.

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. Do you ever see GitHub issue comments where someone posts the results of a reprex with a current package version, and then with an older one, to prove a regression? How would you go about preparing such a report? Today I learnt there is a clean way to have different versions of a codebase at once on your computer, thanks to the ever powerful Git.

As mentioned about a million times on this blog, last year I read Git in practice by Mike McQuaid and it changed my life – not only giving me bragging rights about the reading itself. 😅 I decided to give Pro Git by Scott Chacon a go too. It is listed in the resources section of the excellent “Happy Git with R” by Jenny Bryan, Jim Hester and others. For unclear reasons I bought the first edition instead of the second one.

In my quest to having reading notes on the tech books I read, and while waiting for code to run, I recently re-read The Pragmatic Programmer by David Thomas and Andrew Hunt. That book, whose second edition was published in 2019, offers an overview of many topics useful to programmers, from the idea of taking responsability, to testing, tooling, etc. Not my favorite tone I’m not the biggest fan of the tone used in the book, that feels a bit patronizing to me.

I seem to have at last entered my Git era. 🎉 Reading and applying Git in practice was probably the best thing I did for my upskilling this year. One Git workflow aspect I’ve finally realized is that it’s fine to have two phases of work in a Git branch. I’ll explain it in this post. Set up: create a branch for your work! Ideally, in most cases, when adding a feature or fixing a bug or whatever, I’ll work in a branch.

Another month, another long train trip enjoyed in the company of great books, among which a work-related one, Kill it with fire by Marianne Bellotti. As indicated by its subtitle “Manage Aging Computer Systems (and Future Proof Modern Ones)”, the book deals with handling legacy computer systems. The focus is on bigger projects (including serious internal politics) than what I usually deal with, but there’s some valuable lessons for any project size in there.

My sticky note filled up quickly after I only added setNames() on it, with related functions for dealing with object names, in base R and beyond! (Un)Setting object names: stats::setNames(), unname() and rlang::set_names() I noticed a function ending with something like this: blop <- function() { # code creating the df data.frame # ... names(df) <- c("col1", "col2") df } It struck me as simplifiable by:

While preparing materials for teaching Git a few months ago, I re-read Suzan Baert’s excellent post about Git and GitHub, where she mentioned having read “Git in Practice” by Mike McQuaid. I added the book to my Momox alerts, where it got available a few weeks later. The book source is on GitHub. The book isn’t too heavy, so I took it with me on a long train journey! 🚋

Time for me to throw away my sticky note after sharing what I wrote on it! grep(...) not which(grepl(...)) Recently I caught myself using which(grepl(...)), animals <- c("cat", "bird", "dog", "fish") which(grepl("i", animals)) #> [1] 2 4 when the simpler alternative is animals <- c("cat", "bird", "dog", "fish") grep("i", animals) #> [1] 2 4 And should I need the values instead of the indices, I know I shouldn’t write

When I see a book recommendation somewhere, be it for work or leisure, I often either order the book or set an alert in my favorite online second-hand bookstore. By the time I am notified the book is available, I sometimes don’t remember why I listed it! That’s what happened for the book A Philosophy of Software Design by John Ousterhout. I decided to trust my past self and buy it.

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. Following last week’s post on my testing workflow enhancements, Jenny Bryan kindly reminded me of the existence of an actual reset button when you’ve been interactively running tests that include some “local mess”: withr::local_envvar(), withr::local_dir(), usethis::local_project()… The reset button is withr::deferred_run(). It is documented in Jenny’s article about test fixtures: Since the global environment isn’t perishable, like a test environment is, you have to call deferred_run() explicitly to execute the deferred events.

I spend a lot of quality time with testthat, that sometimes deigns to praise my code with emojis, sometimes has to encourage me. No one gets it right on their first try apparently? Anyway, in honor of testthat 3.2.0 release 🎉 👏, I’d like to mention two small things that improved my testing workflow a whole lot! Running one single test at a time Under testthat 3.2.0 minor features lies a small gem:

Straight from my sticky note, three functions that I like a lot, despite their not being new at all… But maybe new to some of you? sprintf(), the dependency-free but less neat “glue” Imagine I want to tell you who I am. I could write name <- whoami::fullname() github_username <- whoami::gh_username() glue::glue("My name is {name} and you'll find me on GitHub as {github_username}!") #> My name is Maëlle Salmon and you'll find me on GitHub as maelle!

My sticky note is full! And luckily all functions on it can be squeezed into a similar topic: making things smaller! Make lists smaller with purrr::compact(), purrr::keep(), purrr::discard() Once upon a time there was a list (isn’t this the beginning of all R scripts?!) my_list <- list( name = "Maëlle", city = "Nancy", r_problems_encountered = Inf, python_skills = NULL ) Imagine you want to get rid of NULL elements.

There are already three functions of note on a piece of paper on my desk, so it’s time to blog about them! This post was featured on the R Weekly podcast by Eric Nantz and Mike Thomas. How does this package depend on this other package? pak::pkg_deps_explain() The pak package by Gábor Csárdi makes installing packages easier. If I need to start working on a package, I clone it, then run pak::pak() to install and update its dependencies.

I (only! but luckily!) recently got introduced to the magic of purrr::reduce(). Thank you, Tobias! I was told about it right as I was unhappily using many for loops in a package1, for lack of a better idea. In this post I’ll explain how purrr::reduce() helped me reduce my for loop usage. I also hope that if I’m doing something wrong, someone will come forward and tell me! This post was featured on the R Weekly podcast by Eric Nantz and Mike Thomas.

Following my recent post on three useful (to me) R patterns, I’ve written down three other things on a tiny sticky note. This post will allow me to throw away this beaten down sticky note, and maybe to show you one element you didn’t know? nzchar(): “a fast way to find out if elements of a character vector are non-empty strings” One of my favorite testing technique is the escape hatch strategy, about which I wrote a post on the R-hub blog: you make part of your code responsive to an environment variable, and you locally set that environment variable in your tests.

This post was featured on the R Weekly highlights podcast hosted by Eric Nantz and Mike Thomas. I’m happy to report that I thought “oh but I know a better way to write that code!” a few times lately when reading old scripts of mine, or scripts by others. It’s a good feeling because it shows progress! I’ve tooted about all three things I’ll present in this post: After reading Julia Evans’ post about blogging, I decided to train the blogging muscle a bit using these low-hanging fruits/toots1.