Chapter 2 R Style Guide

Adapted from Advanced R by Hadley Wickham

**This guide is only a suggestion and not a requirement.

Good style is important because while your code may have only one author, it will usually have multiple readers. Good coding style is like using correct punctuation. You can manage without it, but it makes things easier to read. As with styles of punctuation, there are many possible variations. The following guide is based on Google’s R Style Guide, with some changes.

2.1 Line Length

Strive to limit your code to 80 characters per line. This fits comfortably on a printed page with a reasonably sized font. If you find yourself running out of room, this is a good indication that you should encapsulate some of the work in a separate function.

2.2 Commenting Guidelines

Comment your code!! Each line of a comment should begin with the comment symbol, #, and a single space. Commenting codes help you and the reader follow what’s going on.

2.3 Assignment

Use <-, not =, for assignment.

  • Good Assignment
    • x <- 5
  • Bad Assignment
    • x = 5

2.4 Notation and Naming

File names should be meaningful and end in .R. Use a dash to separate words within a name.

  • Good File Names
    • fit-models.R
    • utility-functions.R
  • Bad File Names
    • it.R
    • foo.r
    • stuff.r

If files need to be run in sequence, prefix them with numbers.

  • 0-download.R
  • 1-parse.R
  • 2-explore.R

2.5 Object Names

Variable and function names should be lowercase. Use an underscore, _ , to separate words within a name. Generally, variable names should be nouns and function names should be verbs. Strive for names that are concise and meaningful.

  • Good Object Names
    • day_one
    • day_1
  • Bad Object Names
    • Object name is too long
      • first_day_of_the_third_month
      • this_is_way_too_long_of_a_name
    • Words are not separated by an underscore
      • DayOne
      • dayone
    • Object name is not meaningful
      • dttjmc1
      • 2l4p6g8q

Where possible, avoid using names of existing functions and variables. Doing so may cause confusion for the readers of your code.

2.6 Syntax Spacing

  1. Place spaces around all infix operators (=, +, -, <-, etc).

    • Good Syntax Spacing
      • x <- 1:10
      • average <- mean(feet / 12 + inches, na.rm = TRUE)
    • Bad SyntaxSpacing
      • Space needed around operator, <-
        • area<-side^2
        • average<-mean(feet/12+inches,na.rm=TRUE)

  2. There’s a small exception to the spacing rule. The following :, :: and ::: do not need spaces around them.

    • Good Syntax Spacing
      • y <- c(1:10)
      • base::get
    • Bad Syntax Spacing
      • Spaces not needed around colon
        • x <- 1 : 10
      • Spaces not needed before and after ::
        • base :: get

  3. Place a space before left parentheses, except in a function call.

    • Good Syntax Spacing
      • if (debug) do(x)
      • plot(x, y)
    • Bad Syntax Spacing
      • Spaces needed after if and before do
        • if(debug)do(x)
      • Space not needed in function call
        • plot (x, y)

  4. Extra spacing (i.e., more than one space in a row) is ok if it improves alignment of equal signs or assignments. For example,
    list(
      total = a + b + c,
      mean = (a + b + c) / n
    )


  5. Do not put spaces around code in parentheses or square brackets (unless there’s a comma, in which case see above).

    • Good Syntax
      • if (debug) do(x)
      • diamonds[5, ]
    • Bad Syntax
      • No spaces needed around debug
        • if ( debug ) do(x)
      • Space needed after the comma
        • x[1,]
      • Space goes after comma not before
        • x[1 ,]

2.7 Curly Braces

An opening curly brace should never go on its own line and should always be followed by a new line. A closing curly brace should always go on its own line, unless it’s followed by else. Always indent the code, 2 spaces, inside curly braces.

  • Good Syntax

    • if (y < 0 && debug) {
        message(“Y is negative”)
      }
    • if (y == 0) {
        log(x)
      } else {
        y ^ x
      }


  • Bad Syntax

    • if (y < 0 && debug)
      message(“Y is negative”)
    • if (y == 0) {
        log(x)
      }
      else {
        y ^ x
      }
    It’s ok to leave very short statements on the same line such as:
      if (y < 0 && debug) message(“Y is negative”)

2.8 Indentation

When indenting your code, use two spaces. Never use tabs or mix tabs and spaces. The only exception is if a function definition runs over multiple lines. In that case, indent the second line to where the definition starts:
long_function_name <- function(a = “a long argument”,
                            b = “another argument”,
                            c = “another long argument”) {
  # As usual code is indented by two spaces.
}