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 } |
