This website uses cookies to collect usage information in order to offer a better browsing experience. By browsing this site or by clicking on the "ACCEPT COOKIES" button you accept our Cookie Policy.

R Code – Best Practices

The R Trader

Contributor:
The R Trader
Visit: The R Trader

We take a look back at this classic piece from The R Trader on practical tips for Naming conventions, Files organisation, Syntax and Miscellaneous items.

Nothing is more frustrating than a long piece of code with no standard way of naming elements, presenting code or organizing files. It’s not only unreadable but more importantly not reusable. Unfortunately, unlike other programming languages, R has no widely accepted coding best practices. Instead there has been various attempts to put together a few sets of rules. This post is trying to fill the gap by summarizing and/or extracting what I found relevant in those various attempts. It also includes some tips I came up with after years of using R on a daily basis. 

1 – Naming conventions 

R has no naming conventions that are generally agreed upon. As a newcomer to R it’s useful to decide which naming convention to adopt. 

  • There are 5 naming conventions to choose from: 
  • alllowercase: e.g. adjustcolor 
  • period.separated: e.g. plot.new 
  • underscore_separated: e.g. numeric_version 
  • lowerCamelCase: e.g. addTaskCallback 
  • UpperCamelCase: e.g. SignatureMethod 
  • Strive for names that are concise and meaningful 
  • Generally, variable names should be nouns and function names should be verbs. 
  • Strive for names that are concise and meaningful 
  • Generally, variable names should be nouns and function names should be verbs. 
  • Not exported and helper functions always start with “.” 
  • Local variables and functions are all in small letters and in “.” syntax (do.something, get.xyyy). It makes it easy to distinguish local vs global and therefore leads to a cleaner code. 
  • File names should be meaningful and end in .R. 
  • Pick one naming convention and stick to it. My suggestion: 
  • Files: underscore_separated, all lower case: e.g. numeric_version 
  • Functions: period.separated, all lower case: e.g. my.function 
  • Variables: lowerCamelCase: e.g. addTaskCall 

2 – Files organisation 

They way files are organised helps making the code more readable. Similarly, the way the code is organised within a file has a significant impact on readability. Files might also have specific purposes. Some might contain only functions that will be used by other files, some might be used to update packages etc… 

2.1 – How to organise the files within a project? 

  • Use the project facility of RStudio each time you start working on a new project 
  • Keep all of the source files for a project in one directory and use relative paths to access them 
  • Separate files that contain functions that will be used by other parts of the code from the core of the code 
  • Consider what working directory you are in when sourcing a script. 

2.2 – How to organise the code within each file? 

  • Start each file with a comment saying who wrote it and when, what it contains, and how it fits into the larger program. 
  • Then load all required packages. 
  • Then source required files if any 
  • Then your code starts 
  • Break code up into separate files (generally <2000–3000 lines). 

#############################################################

## Stuff I have to do

## thertrader@gmail.com – Feb 2018

#############################################################

​ ##############################

# 0 – Load librairies

##############################

library(zoo)

library(xts)

  ​##############################

# 1 – Source file

##############################

dataPath <- "C:/some_directory/some_sub_directory/"

dataFile <- "some_functions.R"

source(paste0(dataPath,dataFile))

  ##############################

# 2 – Start my code

##############################

myPlot <- plot(data,type="l")

2.3 – Files of functions 

  • Write functions (and even a package) to automate things. Packages require a lot of discipline, documentation, and structure, which really help to enforce best practices 
  • A file of functions must include related functions. 
  • Put function definitions at the top of your file (if not too many). Function names can also be retrieved directly within RStudio. 
  • Each function should have a single, focused task 
  • If a function starts to get really complicated, consider separating parts out as separate functions. (Think reuse) 
  • Precede each function with a comment regarding its task and the format of the input and output. 

#############################################################

## Date Functions

##

## dd.mm.yyyy.to.date: 22.10.2004 to a date

## yyyy-mm-dd.to.date: 2008-07-22 to a date

## dd-mm-yyyy.to.date: 12-05-2001 to a date

##

## thertrader@gmail.com – Jan 2008…

############################################################

  ## 22.10.2004 to a date

dd.mm.yyyy.to.date <- function(theDate) {

 myDate <- as.Date(theDate, format = "%d.%m.%Y")

 return(myDate)

}

  ## 2008-07-22 to a date

yyyy-mm-dd.to.date <- function(theDate) {

 myDate <- as.Date(theDate, format = "%Y-%m-%d")
 return(myDate)

}

  ## 12-05-2001 to a date

dd-mm-yyyy.to.date <- function(theDate) {

 myDate <- as.Date(theDate, format = "%m-%d-%Y")

 return(myDate)

}

2.4 – Files with packages and addins 

  • R and packages can be updated with the installr command on a (Windows) computer that already has R installed but when installing R on a brand new computer or a new operating system another method is needed 
  • For installation on a brand new computer or a new operating system, It’s very handy to keep a file with all packages and addins that you need and install them right after R has been installed for the first time. Below is a template file 

##################################################

## Install Package Automatically – to run after R has been upgraded/installed

##

## thertrader@gmail.com – Aug 2010…

##################################################

  install.packages(c(

“data.table”,

“DEoptim”,

“devtools”,

“dplyr”,

“DT”,

“dygraphs”,

“ggplot2”,

“xts”,

“PerformanceAnalytics”))

  install.packages(“taskscheduleR”, repos = “http://www.datatailor.be/rcube”, type = “source”)

3 – Syntax 

  • Place spaces around all infix operators (=, +, -, <-, etc.). 
  • Use <-, not =, for assignment. 
  • Use comments to mark off sections of code. 
  • Comment your code with care. Comments should explain the why, not the what 
  • Each line of a comment should begin with the comment symbol and a single space 
  • 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 followed by else. 
  • Always indent the code inside the curly braces. 
  • Keep your lines less than 80 characters.This is the amount that will fit comfortably on a printed page at a reasonable size. If you find you are running out of room, this is probably an indication that you should encapsulate some of the work in a separate function. 

4 – Miscellaneous 

  • Use RStudio 
  • Use version control when you start sharing code. RStudio ships with integrated facilities to access GitHub and SVN 
  • Keep track of versions (of data, of functions). 
  • Always start with a clean environment instead of saving the workspace. 
  • Keep track of session information in your project folder. 
  • Keep track of the memory used by your program. 
  • Have someone else review your code: hence this document Shape 😉 

This post has been written using my own experience and the following documents: 

Visit the The R Trader Blog http://www.thertrader.com to get additional tips and samples.

Disclosure: Interactive Brokers

Information posted on IBKR Traders’ Insight that is provided by third-parties and not by Interactive Brokers does NOT constitute a recommendation by Interactive Brokers that you should contract for the services of that third party. Third-party participants who contribute to IBKR Traders’ Insight are independent of Interactive Brokers and Interactive Brokers does not make any representations or warranties concerning the services offered, their past or future performance, or the accuracy of the information provided by the third party. Past performance is no guarantee of future results.

This material is from The R Trader and is being posted with permission from The R Trader. The views expressed in this material are solely those of the author and/or The R Trader and IBKR is not endorsing or recommending any investment or trading discussed in the material. This material is not and should not be construed as an offer to sell or the solicitation of an offer to buy any security. To the extent that this material discusses general market activity, industry or sector trends or other broad based economic or political conditions, it should not be construed as research or investment advice. To the extent that it includes references to specific securities, commodities, currencies, or other instruments, those references do not constitute a recommendation to buy, sell or hold such security. This material does not and is not intended to take into account the particular financial conditions, investment objectives or requirements of individual customers. Before acting on this material, you should consider whether it is suitable for your particular circumstances and, as necessary, seek professional advice.

trading top