Tips & Methodology

  • R is known for having a vibrant open-source community, a steep learning curve, and sometimes cryptic error and warning messages. All of these nuances add up to a great treasure trove of online resources to assist with vexing R code.
  • A tip for debugging your own R code is to try it for 15 minutes and afterwards seek out assistance from teammates.
  • R includes some features for debugging such as the traceback() function which gets and print the call stack. The browser() function interrupts the execution of an expression allows for further inspection. RStudio even has a menu tab dedicated to debugging.
  • Running R code line by line can help identify a problem in the code.
  • Running the “inside” of a function with supplied arguments can help mediate errors that occur when moving ad hoc code to generalized functions.
  • When in doubt about complex errors on specific use cases: use a simpler data set from data() function which shows all of the default data sets that come with R and try to re-create the same error. This is helpful when asking others for help and also removes some of the specific burdens that can be associated with domain-specific data.
  • Check your data types immediately after reading in the data set. Use str() to check for class and object types. Getting a confirmation on class types and objects types can dispel further errors down the road if a function is not applicable to (for example…) factors. Specifying “stringsAsFactors = FALSE” can and will be a frequent headache but there are new packages to make it easier: forcats for working with factors and using the readr package will not automatically convert characters to factor types.
  • To log errors for further analysis and debugging, use the sink() function to send R output to a file. The capture.output() is also another option for this.

Further reading