8 Coding Style Tips for R Programming

R is an open-source programming language that is widely used as a statistical software and data analysis tool. R generally comes with the Command-line interface. R is available across widely used platforms like Windows, Linux, and macOS. Also, the R programming language is the latest cutting-edge tool. Software engineering is not just all about learning a language and building some software. As a software engineer or software developer, you are expected to write good software. Good software can be judged by reading some piece of code written in the project.

If the code is easy to understand and easy to change then definitely it’s good software and developers love to work on that. For a beginner R programmer, it is a good idea to acquire and start using good practices in coding. Google and R-guru Hadley Wickham have excellent tips on R coding style guide. The list contains things that what to do and not to do while programming in R. So in this article we are going to discuss six coding style tips that help you to become a better programmer in R language.

1. Commenting

It’s a common thing that developers use comments to specify the purpose of a line in their code. It’s true that comments are really helpful in explaining the code what it does but it also requires more maintenance of the code. Sometimes it is very important, for example…if you are dealing with a third-party API where you need to explain some behavior there one can use comments to explain the code but don’t write comments where it’s not necessary. So in R programming always start commenting a line with the comment symbol # and one space. Hadley Wickham suggests to use the remaining of commented lines with – and = to break up the file into easily readable chunks. Please refer to the below sample code snippet: 

R

# Read table ----------------------------------
# Read table ==================================

2. Assignment

R has an unusual assignment operator ‘<-‘  instead of ‘=’ sign. So it’s a good practice to use the ‘<-‘ sign, instead of the ‘=’ sign. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
x <- 10

Bad Practice:

R

# Bad Practice
x = 10

3. File Names

The name of the file should be meaningful and end with ‘.R’. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
fit-models.R
linear-regression.R

Bad Practice:

R

# Bad Practice
models.R
stuff.R

If files need to be run in sequence, prefix them with numbers as shown below:

R

0-fit-models.R
1-linear-regression.R
2-neural-network.R

4. Object Names

“There are only two hard things in Computer Science: cache invalidation and naming things.”

— Phil Karlton

Variable and function names must be in lowercase. Use an underscore ‘_’ to separate words within a name. Generally, variable names should be nouns, and function names should be verbs. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
number_of_students
get_price

Bad Practice:

R

# Bad Practice
GetPrice
getprice

5. Spacing

Put a place spaces around all infix operators (=, +, -, <-, etc.). The same rule implements when using = in function calls. Always put a space after a comma, and never before. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
perimeter_of_rectangle = 2(length + width), na.rm = TRUE)

Bad Practice:

R

# Bad Practice
perimeter_of_rectangle=2(length+width),na.rm=TRUE)

There’s a small exception to this rule e.g in case of :, :: and ::: don’t need spaces around them. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
x <- 1:20
value::real

Bad Practice:

R

# Bad Practice
x <- 1 : 20
value :: real

Put a space before left parentheses, except in a function call. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
if (yes) do(x)
run(x, y)

Bad Practice:

R

# Bad Practice
if(yes)do(x)
run(x, y)

Do not put spaces around code in parentheses or square brackets except there’s a comma. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
student[1, ]

Bad Practice:

R

# Bad Practice

# Needs a space after the comma
student[1,]

# Put space after comma not before
student[1 ,]

6. 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. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
if (x > 0 && foo) {
  cat("X is positive")
}

if (x == 0) {
  log(a)
} else {
  a ^ x
}

Bad Practice:

R

# Bad Practice

if (x > 0 && foo)
cat("X is positive")

if (x == 0) {
  log(a)
}
else {
  a ^ x
}

It’s fine to write very short statements on the same line as shown below:

R

# Good Practice
if (x > 0 && foo) cat("X is positive")

7. Line Length

Try to limit the code to 80 characters per line. This fits comfortably on a printed page with a reasonably sized font. 

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. Please refer to the below sample code snippet: 

Good Practice:

R

# Good Practice
function_name <- function(a = "a long argument",
                          b = "another argument",
                          c = "another long argument") {
  # As usual code is indented by two spaces
}