Don’t Repeat Yourself (DRY)

Probably everyone who has done some kind of programming has heard of the “Don’t Repeat Yourself” (DRY) principle. In a nutshell, it’s about reducing code redundancy for the purpose of reducing error and enhancing readability.

Undoubtedly the most common manifestation of the DRY principle is the creation of a function for re-used logic. The “rule of 3” is a good shorthand for identifying when you might want to rethink how your code is organized– “You should consider writing a function whenever you’ve copied and pasted a block of code more than twice (i.e. you now have three copies of the same code)”, per the R For Data Science book

The DRY principle can be applicable to other settings as well. For example, data scientist David Robinson once remarked (probably only half jokingly) that one should write a blog post after giving the same piece of advice three time. ¹

DRY and R Packages

I’d like to suggest applying the DRY principle to package creation–if you use a set of 3 functions at least 3 times, then you should put them in a package. In fact, there need not be more than 1 function or 1 use case–given that the function or use case is significant enough–to justify the initiation of a package.

Well-known R community member Bob Rud–who is among the most active R developers– has made creating minimal, useful R packages commonplace. In his description of his Stack Overflow Driven Development, he suggests that not only is such a practice useful for abstracting functionality, but it can also be a great way to enhance one’s skills while helping others.

If one is fearful of creating a package–perhaps due to the potential responsibility of having to maintain it if it is used by others–then I would suggest creating a “personal” package (that you don’t really intend to be used by anyone else). In fact, I believe it is fairly common practice for active R users to have their own personal packages. ² For example,

• Bob Rud’s {hrbrmisc} and hrbrthemes
• David Robinson’s {drlib}
• Julia Silge’s {silgelib}
• Strenge Jack’s {sjmisc}, {sjPlot}, {sjstats}, and {sjlabelled}

Following the examples of others, I have created several personal packages for atomic purposes. ³

• {tetext} for Tidy Text Mining principles.
• {teplot} for plotting functions.
• {teproj} for project-related functions.

Examples

To give an example of how such a package can be useful, I’ll describe some recent additions to my {teplot} package to assist with geo-spatial visualization of single U.S. states.

I was working on something related to high schools in Texas (look out for a blog post in the future) and was beginning to copy-paste some functions that I had used for another project for visualizing geo-spatial data in the state. The moment I thought about reusing the code was the moment that I realized that I should put it in a package. Now, visualizing geo-spatial data in Texas is as easy as follows.

library("ggplot2")
library("teplot")
library("ggmap")
library("dplyr")

path <- "https://raw.githubusercontent.com/tonyelhabr/uil-v02/master/data/schools-nces-join.csv"
schools_geo <- readr::read_csv(path)

viz_map_base <-
  teplot::create_map_state(state = "texas", show_county = FALSE) +
  teplot::theme_te() +
  teplot::theme_map()

viz_map_bycnts <-
  viz_map_base +
  geom_polygon(
    data =
      schools_geo %>%
      count(county) %>%
      inner_join(
        teplot::get_map_data_county_tx(),
        by = c("county" = "subregion")
      ),
    aes(fill = n)
  ) +
  scale_fill_gradient(
    trans = "log",
    low = "white",
    high = "red"
  ) +
  theme(legend.position = "none")
viz_map_bycnts

I also added a stamen map to the package data so that I can use it easily as a base layer.

viz_map_bycnts_stamen <-
  teplot::ggmap_stamen_tx +
  geom_point(
    data = schools_geo,
    aes(x = lon, y = lat),
    color = "red",
    size = 1
  )
viz_map_bycnts_stamen

To give a separate example, I used my {tetext} package for nearly all of the code in the flexdashboard that I created for analyzing the Twitter acccounts of NBA teams. There, I simply called the function tetext::visualize_time_facet() to generate a fairly illustrative visual.

viz_time_facet_all <-
  data_facet_trim %>%
  tetext::visualize_time_facet(
    timebin = timestamp,
    color = id,
    facet = id,
    scale_manual_config = list(values = colors_filt),
    facet_config = list(scales = "fixed"),
    labs_config = list(title = NULL)
  )
viz_time_facet_all

Getting Started

If one has no experience with creating packages and does not know where to get started, there are plenty of awesome resources out there to learn more about it. To name a few:

• Hillary Parker’s “famous” blog post
• R Packages book by Hadley Wickham
• Karl Broman’s primer
• Jenny Bryan’s class tutorial

(There’s a good reason why these resources show up at the top of a Google search for “R packages”.)

Although it may seem daunting at first, one should realize that the pay-off will be great. (Just think about how much time, effort, and debugging you save when writing a function. Now scale that feeling by the number of functions that you include in your package!) I created my first package to assist with using my company’s color scheme in plots. Up until that point, I had been needlessly copy-pasting the same hex values into each separate project where I wanted to use the color palette. (If this happens to be your use case, then check out Dr. Simon J’s blog post on exactly this topic!)

Conclusion

Even if it you don’t program much (or at all), the DRY principle will undoubtedly be applicable to you at some point in time. If you’re working with R, then I suggest using packages as a solution to your DRY problems.