code review example R code Caret
PSA, rblog

Code Review Example R Code Caret

Today we will go through a practical code review example. I will analyze some code chunks I used during the Kaggle ACEA challenge. The code chunks come from a function I used to run my final model using Caret in R. Code review is a very important step in any project, I recommend doing it after any project. It helps condense your code and make it more efficient. In doing so it also allows you to share and preserve your work more efficiently. In this blog I will follow the top 3 of my checklist I shared earlier.

Obviously I am reviewing my own code in these examples, this is different from reviewing someone elses code. The simplest difference is that your not the original author, I already know what the code is supposed to achieve. In practical examples the first step is actually making sure you understand how the code works. After all how can you review something without understanding it?

If you want some background on the code, I used this function during the ACEA Smart Water Analytics Challenge on Kaggle. Its function is discussed in more detail here. In short, this function was designed to run the final model I ended up using for this challenge on all available datasets.

You can find the full unedited code in this github, named ‘modelling_function.R’. I will now go through some code chunks. This code hasn’t been reviewed or optimized since I did the project, and there is alot of room for improvement.

Code Review Example Function Headers

The code chunk below shows the header of my helper function wrapper.

model_handmade_folds <- function(data, horizon, dataset, lag, features, basefeatures){
  #basefeatures <- 'Depth'
  # Make lags:
  features <- grep(features,names(data),value = T)
  basefeatures <- grep(basefeatures,names(data),value = T)

There are 2 standout issues I noticed immediately and that should be addressed in order to improve this function. As described in my checklist on code review, helper functions are amazing in R code. But they are only amazing if done correctly. If done correctly they improve code readability and transfer between projects. Lets focus on readability.


the first issue is no explanation of the functions inputs. Basic explanation should include an example input and short descriptions of type and shape. The second is explanation of the functions use case, explain this shorthand at the function wrapper. Thirdly it is important to explain the output of the function in the wrapper. Finally reevaluate the name of the function, does it clearly relate to the shorthand explanation of its purpose.

All these alterations also improve its transferability to other projects. There is a secondary issue in this functions first 5 lines. The parameters ‘features’ and ‘basefeatures’ used as input for the function are immediately reassigned. This is bad coding practice as there is no reason why the reassigned variables couldn’t have been used as original input for the function.


The revised code is shown below. It now contains a precise explanation of all inputs, the functions use case and its output. The name of the function has been altered and the parameters more appropriately renamed. The reassignment of the 2 input parameters is removed and incorporated them into our function inputs/wrapper.

LLTO_Model <- function(data, name_of_dataset, lag, time_out_horizon, features, predictors){
  ## Function purpose: Use Leave Location and Time Out Moddeling (LLTO) on the 
  ## DataSets of the Kaggle ACEA Smart Water Analytics Challenge. Datasets are 
  ## time series with multiple predictors and features. Lags are used as features.
  ## A horizon gets specified to model the Time Out Cross validation.
  ## Function Output: Train Object
  ## Function input:
  # data                Dataset from Kaggle Acea Smart Water Analytics challenge, 
  #                     containing Date, numeric predictors & feature set
  # name_of_dataset     Name of input dataset, used to save trained model
  # lag                 Amount of lags used for features (integer input)
  # time_out_horizon    Horizon of folds used in Time Out Cross validation
  # features            Names of features used in dataset (numeric variables)
  # predictors          Names of predictors used in dataset (numeric variables)

Code Review Example Preprocessing Setup

The next part of the function runs through the different data preprocessing steps before the model training begins. From a user perspective I expect some control over this piece of code. As a user of a function you need these options to make it transferable. The different preprocessing steps need to be more precisely explained aswell. I also have some thoughts on code placement inside this segment.

  for(i in 1:length(features)){
    for(j in 1:lag){
      data$temp <- Lag(data[,features[i],+j])
      names(data)[which(names(data)=='temp')] <- paste(features[i],j, sep = '_')
  data <- data[,which(colMeans(!>.2)]
  # Inlude seasonality:
  data$year <- as.numeric(substr(data$Date,7,10))
  data$year <- data$year - min(data$year) + 1
  data$month <- as.numeric(substr(data$Date,4,5))
  data$quarter <- ifelse(data$month <= 3,1,
                         ifelse(data$month >=4 & data$month <= 6,2,
                                ifelse(data$month >=7 & data$month <= 9,3,
                                       ifelse(data$month >9,4,NA))))
  data_long <- tidyr::pivot_longer(data, predictors,names_to = 'location', values_to = 'depth_to_groundwater')
  data_long <- data_long[complete.cases(data_long),]
  data_long <- data_long[which(data_long$depth_to_groundwater != 0),]
  #data_model <- data_long[,-grep('location|Date|name',names(data_long))]
  temp <- data_long[,which(!names(data_long)%in%c('depth_to_groundwater','Date','location'))]
  nzv <- nearZeroVar(temp)                                                       # excluding variables with very low frequencies
  if(length(nzv)>0){temp <- temp[, -nzv]}
  i <- findCorrelation(cor(temp))                                                # excluding variables that are highly correlated with others
  if(length(i) > 0) temp <- temp[, -i]
  i <- findLinearCombos(temp)                                                    # excluding variables that are a linear combination of others
  if(!is.null(i$remove)) temp <- temp[, -i$remove]
  data_model <- data_long[,c('depth_to_groundwater','Date','location', names(temp))]
  data_model$Date <- as.Date(as.character(data_model$Date), format = '%d/%m/%Y')

Preprocessing steps explained

The code above consists of 5 preprocessing distinct steps:

  • Feature addition
  • data shaping for modeling
  • Removal of missing information
  • Statistical preprocessing steps
  • variable formatting

In the current code none of these steps are explained or identified as such. It is up to the reader of the code to figure this out. In the code below I explained these different distinct steps so they can be located easier. They can also be adjusted to a new project or dataset more easily. It is now easier to evaluate them individually and improve on the function.

Code placement

There is an argument here that the preprocessing steps need to be placed into their own function entirely. It is a distinct use case that can be seperated from training the model. Sometimes it even is a requirement in a production environment. This happens when we have to preprocess live production data as we did when training the model. The code is already greatly improved simply by reordening it into the 5 steps above.

Other considerations

One of the concerns I have reading this part of my code back is the lack of stepwise explanations. A clear example is the section on missing values, its as simple as it gets. Remove all rows that even contain a single missing value. As a new reader or user I want to know so many more things about this choice. This includes the impact of this choice, what if it removes all rows? The alternatives that were investigated and even why it removes the missing values.

Code review comes in to make projects stand up to production level quality. You could argue that this level of detail is prohibitive but I am here to argue it is a requirement. When this model is in operation any issue may arise, perhaps the missing data increases and the model fails specifically on this point. A developer may start a new project to implement imputation techniques. Maybe you already investigated this and it led to a dead end. One of the key characteristics of production level code is its ability to handle diverse outcomes and report on them accordingly.

  ## Variable formatting:
  # Date variable:
  data_model$Date <- as.Date(as.character(data_model$Date), format = '%d/%m/%Y')
  ## Feature addition:
  # Creating lags for i features in j lags
  for(i in 1:length(features)){
    for(j in 1:lag){
      data$temp <- quantmod::Lag(data[,features[i],+j])
      names(data)[which(names(data)=='temp')] <- paste(features[i],j, sep = '_')
  # Inlude seasonality:
  data$year    <- as.numeric(substr(data$Date,7,10))
  data$year    <- data$year - min(data$year) + 1
  data$month   <- as.numeric(substr(data$Date,4,5))
  data$quarter <- ifelse(data$month <= 3,1,
                         ifelse(data$month >=4 & data$month <= 6,2,
                                ifelse(data$month >=7 & data$month <= 9,3,
                                       ifelse(data$month >9,4,NA))))  
  # remove uncommon newly created features:
  data <- data[,which(colMeans(!>.2)]
  ## Data shaping for modelling
  # Long format by predictors for LLTO modelling:
  data_long <- tidyr::pivot_longer(data, predictors,names_to = 'location', values_to = 'depth_to_groundwater')
  ## Remove missing variables:
  # Complete cases
  data_long <- data_long[complete.cases(data_long),]
  ## Statistical preprocessing:
  # Remove outliers
  data_long <- data_long[which(data_long$depth_to_groundwater != 0),]
  # Preprocess features for modelling
  temp <- data_long[,which(!names(data_long)%in%c('depth_to_groundwater','Date','location'))]
  # excluding variables with very low frequencies
  nzv <- nearZeroVar(temp)                                                       
  if(length(nzv)>0){temp <- temp[, -nzv]}
  # excluding variables that are highly correlated with others
  i <- findCorrelation(cor(temp))                                               
  if(length(i) > 0) temp <- temp[, -i]
  # excluding variables that are a linear combination of others
  i <- findLinearCombos(temp)                                                   
  if(!is.null(i$remove)) temp <- temp[, -i$remove]
  # Selection of final feature set
  data_model <- data_long[,c('depth_to_groundwater','Date','location', names(temp))]

Code Review Example Cross validation indices

One of the implementations of this function is the handmade folds for cross validation. I implemented this in the code because there were no libraries that used LLTO modelling exactly how I wanted to use it here. Looking back at my checklist, this is an important stage to bring up library optimization. Here we have a usecase where our code deliberately includes a selfprogrammed aspect, and it is our responsibility as the reviewer to verify that this was correct.

In this particular case I know that there is a CAST package in R that claims to implement LLTO modelling, but I found that it didn’t create the folds for cross validation correctly. This is however not documented in the code below, which is a mistake. The code should reflect this piece of research (perhaps even so far as to show its wrong implementation). This also draws back to my previous point regarding the stepwise documentation. It is a smart move to keep initial implementations and checks of code so that later you can reuse your research to back up your final output. I have failed to do so and hence I am open to critism about why I self-programmed this set of functions.

The function of the code below is to create indices of cross validation folds for every predictor and time period defined in the dataset. Only the first time period is excluded as there is no prior data that can be used to train for it. For example a dataset with 4 predictors and 4 time periods gets 12 folds. Caret expects a names list item that includes the elements ‘IndexIn’ and IndexOut’.

# Handmade indexes:
  index_hand_design <- function(data,period, location, horizon, location_one = NULL){
    horizon2 <- max(period)-horizon
      indexin <- which(data$Date >= min(period) & data$Date <= horizon2)
      indexout <- which(data$Date > horizon2 & data$Date <= max(period))
    } else {
      indexin <- which(data$Date >= min(period) & data$Date <= horizon2 & data$location != location)
      indexout <- which(data$Date > horizon2 & data$Date <= max(period) & data$location == location)
    output <-c(list(indexin),list(indexout))
  periods <- round(length(seq.Date(from = min(data_model$Date),to = max(data_model$Date), by = 'day'))/horizon,0)
  dates   <- seq.Date(from = min(data_model$Date),to = max(data_model$Date), by = 'day')
  indices <- 1:periods*horizon
  periods_final <- dates[indices]
  periods_final <- periods_final[!]
  for(i in 3:length(periods_final)){
    output <- list(c(periods_final[i-2], periods_final[i]))
    if(i <= 3){
      output_final <- output
    } else {
      output_final <- c(output_final, output)
  locations <- unique(data_model$location)
  for(i in 1:length(locations)){
    for(j in 1:length(output_final)){
        output_temp <- index_hand_design(data_model,output_final[[j]], locations[i], horizon, location_one = 'yes') 
      } else {
        output_temp <- index_hand_design(data_model,output_final[[j]], locations[i], horizon)
      if(j == 1){
        final_inner <- output_temp
      } else {
        final_inner <- c(final_inner, output_temp)
    if(i == 1){
      final <- final_inner
    } else {
      final <- c(final, final_inner)
  index_final <- list(index = final[seq(1, length.out = length(locations)*length(output_final), by = 2)], 
                      indexOut = final[seq(2, length.out =length(locations)*length(output_final), by = 2)])

Code function

I find this part of the code hard to understand and read. My excuse is that it was written under time pressure after I found out it had to be done by hand. It is however a prime candidate for this reason to review here.

One of the problems is that original function, “index_hand_design”. I will refer back to section 1 about how to properly design helper functions. All problems discussed with the entire function apply to this inner helper function. There is also an argument to not define a function within a function.

To finish off these practical examples I would like to show how to change the nested for loop I used to run the index_hand_design function. Removing for loops is at the highest point of my code review checklist . Below is that code segment changed into an lapply and mapply format.

    final_inner <- lapply(1:length(output_final), function(x){index_hand_design(data_model,
                                                                                location_one = 'yes')})
    # Create dataframe with possible combinations:
    sequences <- data.frame(location = rep(locations,length(output_final)), 
                                           lengths = rep(1:length(output_final), length(locations)))
    final <- mapply(index_hand_design, data = data_model, sequences[,2], sequences[,1], horizon = horizon)

The code above is endlessly more concise then the initial nested for loop. In my final pieces of code I always focus on replacing any remaining for loops into lapply or when using nested for loops mapply.

Wrapping up code review example of R Code in Caret

There were some other problems in the cross validation section, which will end up in the final code on github. I highlighted the removal of the nested for loop as a practicle example. The function was almost done anyway. It is very revealing to work through your own code from a code review perspective. I definitly recommend investing the time in optimizing your work in this way. Hopefully these practicle examples benefit your own work.

code review example R code Caret
Code review checklist R code edition
Blog, PSA, rblog

Code Review Checklist R Code Edition Top 3

Great code review is one of the most underrated skills a Data Scientist can have. In this blog I will share my top 3 code review checklist, specifically for R Code. In our data science team we regularly do code review to make sure it is up to the standard it needs to be. The top 3 elements mentioned in this blog should in my opinion be included in any code review for R code.

One of the greatest pitfalls of code review is developer bias. The goal of code review is to create the best code, not the code you as a developer like the best. I can’t claim this blog is completely whiped clean of developer bias, we all have it. For me it is the main reason why I disliked code review so much. I wanted to write the code I like best. My reasoning was that if it works, why does it even matter how it works. Over the years I have learned as members of our team come and go what code review can add. By using best practices we design our code to be better understood and easier to maintain. Anyway, here is my code review checklist Top 3.

R Code Review Checklist: 1. Helper Functions

Helper functions are without a doubt my number 1 on any code review checklist. It is not an understatement that every for loop ever written in the R language should be replaced with a helper function. When I review someone elses code this is the first scan I make. At its core R is a functional programming language, this should say alot on why we should put focus on this aspect. Some other reasons are:

Code Seperation

The benefits of helper functions are many, for me, since I love a great function it is also makes code easier to read. But seriously, one of the main reasons for me is actually how it seperates your code into concise chunks. Great production ready code consists of a central script that loads different helper functions as needed. In the helper functions the actual data processing, modelling, etc is performed. As a reviewer of your code this allows me to evaluate it in the context of what this specific code chunk is ment to do.

Transferability of Helper Functions

Once we build our code in functional chuncks/functions, it allows us to improve transferability of our code. This is true both for projects and colleagues. A core benefit of code review in R is that it allows you and your team to derive a core set of functions for your company data. Ultimately these functions could be gathered and transformed into a company package.

I started this segment by focusing on for loops, in reality helper functions should be more common. Helper functions are helpful to prevent repitition not only through for loops but also through cross-project functionality. So if I see a step written out in a colleagues code which has a high likelihood of being in need of repitition, I will mark it as a potential helper function.

R Code Review Checklist: 2. Package Optimization

What I remember most from starting out with R is the bewonderement of packages. Now I never had much other programming experience so stick with me on this. What was this magic that you could load functions to do stuff to your data as needed? And there are currently how many packages on Cran? The answer is 17260 packages. Thats a hole lot of code read to work with for you in your projects. One of the great skills an experienced developer can have is to be library agnostic, and this is my focus when reviewing code.

Why We Dont Hammer Down Screws

What exactly is library agnostic? it means that you are willing and capable to switch packages when needed. I’m trying to put emphasis on using the right tool for the right job, this should be a central element in code review. An area where this long was a problem for me is BaseR, I would nearly always use BaseR code as this is what I learned and was comfortable with. I had no immediate reason to use packages such as the tidyverse or data.table, my code was working fine. But it ended up holding me back, because I was incapable of switching packages as needed my code was inefficient in specific areas.

It is in my top 3 jobs of the reviewer to identify these areas and give feedback on optimizing the usage of packages. Look at what packages might fit the specific use case, what packages are implemented in the code? When providing feedback in this area I like to explain different options and their potential benefit (speed, understandability, etc). This in my opinion also helps the reviewer think more about the code and is an area that benefits both.

R Code Review Checklist: 3. Code Placement

When I write an initial script for a project, it always starts out quite structured. Its like a ritual, load data, select, transform, make visualizations, etc. But then one thing always happens, I notice something in my output, a weird pattern. Perhaps its a colleague that wants a slight alteration of the insights. What happens to my code now? I end up placing a quick filter on row 241. A week goes by, maybe even a month goes by, I revisit the project. The scope has changed slightly and I start adding code again.

If you are lucky this is a project that ends at some point, and your code gets retired with it. But what if it becomes a success? We are going to need production ready code that is shareable within the organization. Code review is all about this, we focus on reordering and optimizing code placement. As a code reviewer split the code in front of you into use cases and their approriate chunks. If someone loads data outside the ‘load_data’ chunk, mark it. If someone filters their data within a data visualization, mark it.

The value of great code placement is difficult to overestimate. It hits all the relevant boxes of code review. It improves readability of code and transferability between projects, and very often increases its functionality too.

Wrapping Up Code Review Checklist

These 3 points together make up the core of my code review, and belong on any code review checklist. These 3 points also have one thing in common. They all focus on outer appearance of code, I am a strong believer that this is the biggest benefit of code review. By optimizing readability and transferability we create synergies within data science teams and proejcts that are much needed.

You will find online articles that see validation of the output of code as part of code review. I personally think that any validation is part of the code writing process itself. If you dont have checks and balances in your code that validates your inputs and outputs thats a big problem. The role of the code reviewer is to check for these elements, but they are not responsible for writing or doing it themselves.

This blog was very focused on the ‘how’ of code review. If you are interested in an introduction on the what and why of code review, why it benefits your team or company or a practical example of code review I will release content on those subjects soon. Hopefully put together some of it can benefit you in starting out with code review.