Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mine "Code style" from r-pkgs for nuggets of wisdom #122

jennybc opened this issue Feb 5, 2019 · 1 comment


None yet
2 participants
Copy link

commented Feb 5, 2019

The section "Code style" from the "R code" chapter has been removed, in favour of the treatment of this topic here. I'm pasting the removed text here, so @hadley can read it once and make sure all the best parts are, indeed, included here somewhere.

Code style {#style}

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 I strongly recommend that you use a consistent style and you document it. If you're working on someone else's code, don't impose your own style. Instead, read their style documentation and follow it as closely as possible.

Good style is important because while your code only has one author, it will 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 notes on the website before using it. It's as easy as:


A complementary approach is to use a code linter. Rather than automatically fixing problems, a linter just warns you about them. The lintr package by Jim Hester checks for compliance with this style guide and lets you know where you've missed something. Compared to formatR, it picks up more potential problems (because it doesn't need to also fix them), but you will still see false positives.


Object names

Variable and function names should be lowercase. Use an underscore (_) to separate words within a name (reserve . for S3 methods). Camel case is a legitimate alternative, but be consistent! Generally, variable names should be nouns and function names should be verbs. Strive for names that are concise and meaningful (this is not easy!).

# Good

# Bad

Where possible, avoid using names of existing functions and variables. This will cause confusion for the readers of your code.

# Bad
c <- 10
mean <- function(x) sum(x)


Place spaces around all infix operators (=, +, -, <-, etc.). The same rule applies when using = in function calls. Always put a space after a comma, and never before (just like in regular English).

# Good
average <- mean(feet / 12 + inches, na.rm = TRUE)

# Bad

There's a small exception to this rule: :, :: and ::: don't need spaces around them. (If you haven't seen :: or ::: before, don't worry - you'll learn all about them in namespaces.)

# Good
x <- 1:10

# Bad
x <- 1 : 10
base :: get

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

# Good
if (debug) do(x)
plot(x, y)

# Bad
plot (x, y)

Extra spacing (i.e., more than one space in a row) is ok if it improves alignment of equal signs or assignments (<-).

  total = a + b + c, 
  mean  = (a + b + c) / n

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

# Good
if (debug) do(x)
diamonds[5, ]

# Bad
if ( debug ) do(x)  # No spaces around debug
x[1,]   # Needs a space after the comma
x[1 ,]  # Space goes after comma not before

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 inside curly braces.

# Good

if (y < 0 && debug) {
  message("Y is negative")

if (y == 0) {
} else {
  y ^ x

# Bad

if (y < 0 && debug)
message("Y is negative")

if (y == 0) {
else {
  y ^ x

It's ok to leave very short statements on the same line:

if (y < 0 && debug) message("Y is negative")

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.


When indenting your code, use two spaces. Never use tabs or mix tabs and spaces. Change these options in the code preferences pane:


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.


Use <-, not =, for assignment.

# Good
x <- 5
# Bad
x = 5

Commenting guidelines

Comment your code. Each line of a comment should begin with the comment symbol and a single space: # . Comments should explain the why, not the what. \index{comments}

Use commented lines of - and = to break up your file into easily readable chunks.

# Load data ---------------------------

# Plot data ---------------------------

This comment has been minimized.

Copy link

commented Feb 5, 2019

Yeah, I think that's all included already.

@hadley hadley closed this Feb 5, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.