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.

8-Coding-Style-Tips-for-R-Programming

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



filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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

filter_none

edit
close

play_arrow

link
brightness_4
code

# Good Practice
x <- 10

chevron_right


 

Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

# Bad Practice
x = 10

chevron_right


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

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

# Bad Practice
models.R
stuff.R

chevron_right


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

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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



filter_none

edit
close

play_arrow

link
brightness_4
code

# Good Practice
number_of_students
get_price

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

# Bad Practice
GetPrice
getprice

chevron_right


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

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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



filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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

Good Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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



filter_none

edit
close

play_arrow

link
brightness_4
code

# Good Practice
student[1, ]

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

# Bad Practice
  
# Needs a space after the comma
student[1,]
  
# Put space after comma not before
student[1 ,]

chevron_right


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

filter_none

edit
close

play_arrow

link
brightness_4
code

# Good Practice
if (x > 0 && foo) {
  cat("X is positive")
}
  
if (x == 0) {
  log(a)
} else {
  a ^ x
}

chevron_right


Bad Practice:

R

filter_none

edit
close

play_arrow

link
brightness_4
code

# Bad Practice
  
if (x > 0 && foo)
cat("X is positive")
  
if (x == 0) {
  log(a)
else {
  a ^ x
}

chevron_right


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

R

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right


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

filter_none

edit
close

play_arrow

link
brightness_4
code

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

chevron_right





My Personal Notes arrow_drop_up

Technical Content Engineer at GeeksForGeeks

If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.


Article Tags :

1


Please write to us at contribute@geeksforgeeks.org to report any issue with the above content.