This posting is about various “R Style Guides”, talking about best practices for R programming. Here, I will offer some choices, and let you decide for your organization. The intent is for good software development, which includes helping your code be readable and maintainable by others.
Sometimes constraints exist with other systems that you may be working with, if you are moving data sets around. Some systems, such as MongoDB, may not allow periods in variable names. It is good to find out the constraints of all the software in your system, before defining your local best practices.
Hadly Wickham, Stat 405
Good coding style is like using correct punctuation. You can manage without it, but it sure makes things easier to read. As with styles of punctuation, there are many possible variations. The following guide describes the style that I use (in this book and elsewhere). It is based on Google’s R style guide, with a few tweaks. You don’t have to use my style, but you really should use a consistent style.
Good style is important because while your code only has one author, it’ll usually have multiple readers. This is especially true when you’re writing code with others. In that case, it’s a good idea to agree on a common style up-front. Since no style is strictly better than another, working with others may mean that you’ll need to sacrifice some preferred aspects of your style.
The formatR package, by Yihui Xie, makes it easier to clean up poorly formatted code. It can’t do everything, but it can quickly get your code from terrible to pretty good. Make sure to read the introduction before using it.
Hadly Wickham, Stat 405
Good style is important because while your code only has one author, it will usually have multiple readers, and when you know you will be working with multiple people on the same code, it’s a good idea to agree on a common style up-front.
Google’s R Style Guide
Lists 18 rules in the style guide
R Style. An Rchaeological Commentary
by Paul Johnson, Feb 24, 2016
1 Introduction: Ugly Code that Runs
Because there is no comprehensive official R style manual, students and package writers seem to think that there is no style whatsoever to be followed. While it may be true that “ugly code runs,” it is also 1) difficult to read and 2) frustrating to extend, and 3) tiring to debug. Code is a language, a medium of communication, and one should not feel free no ignore its customs. After students have finished a semester of statistics with R, they may be ready to start preparing functions or packages. Those R users are the ones I’m trying to address with this note. It is important to realize that the readability of code makes a difference. It sometimes difficult to know that there is a “right way” and a “wrong way” because there are so many examples to study on CRAN.
This note describes R style from an Rchaeological perspective. By examining the work of the R Core Development Team (R Core Team, 2012) and other notable package writers, we are able to discern an implicit style guide. However, this note is not “official” or endorsed from R Core.2 With one exception at the end of this note, none of the advice here is “my” advice. Instead, it is my best description of the standards followed by the leading R programmers. At one point, the only guide was the Google R style guide,3 which was used as a policy for R-related “Google Summer of Code” projects. There are many excellent suggestions in Hadley Wickham’s Style Guide.4 In what follows, I’ll try to explain why there are some variations among these projects and offer some advice about how we (the users) should sort through their advice.