Chapter 5 Naming Conventions

This chapter is crucial only for people to understand what are the bad naming practices we the R users have acquired over the years because of flexibility in the language. These names we give to the data or variables are not valid outside or R community and thus are subject to code reviews. You may even be asked to change name before deploying the code in production. The more bad naming practices the more time it takes you to fix them. It’s a good practice to know the best practices for naming things in general.

5.2 Informative Names

I may sound like a tidyverse fanboy ( I am not) but classes and data types in R are quite opaque so names of functions and objects should reflect precisely what they represent. There is no harm in using names with data-types before them

# int_currency <- 1:10
# chr_letters <- letters
# dt_mtcars <- data.table::data.table(mtcars)
# tbl_mtcars <- tibble::tibble(mtcars)

Above advice may be more useful for package developers but it can be used in broad scenarios even on a project where there are multiple working on a same project. If I know what datatype I am dealing with I don’t have to go through the entire code and working on top of it becomes that much easier.

You can use more descriptive names without data types in the beginning for your projects. Names like data, mainData, dummyVar, tempList etc.. should never be used in a project. Use more descriptive names like sales_data_2020, api_token, rate_of_interest etc…

5.3 Conclusions

Proper naming conventions will help collaboration in big teams and it makes the code easier to maintain. We should all strive for better names in the code. It’s the hardest job to come up with new and unique names for a variable everytime you create one but this is the difference between an average programmer and a good one.

  1. Choose a naming convention and stick to it
  2. Don’t include dots ( . ) in names
  3. Use informative names