Prioritize...
After reading this section, you should be able to follow the debugging process, google problems effectively, and find solutions for the some of the more common errors you may encounter in R.
Read...
Learning to code is like learning a new language. It’s hard, you’ll stumble, you’ll make mistakes, but learning to correct those mistakes is one of the most important parts of the process. If you mispronounce a word, you don’t just move on, you keep trying until you get the pronunciation right. Similarly, in coding, you can’t just move on in the code if there’s an error. You must keep trying until you fix the code and it runs smoothly. The good thing about coding is that once you figure out the debugging process for one language, you can apply it to almost all languages. The content here is meant to guide you and help you along in the debugging process. My goal is for you to become self-reliant when it comes to coding errors. Asking questions and seeking help is still a part of the process! I’m just not the first step.
Debug 101
There is no set process for debugging. The route I take to debug will be different from the route that you take; it comes down to personal preference. As you write more and more code, your debugging method will be refined. But if you are just starting to code, it can be quite challenging to know where to even begin. Therefore, I will present my debugging process. You don’t need to follow it step-by-step; it’s merely here to show you what I do when I get a coding error.
- I start by opening RStudio and clearing out everything. It’s important to start with a clean slate. To do this, I run the command rm(list=ls()). This clears out the environment.
- Before debugging, I actually highly recommend you perform this step and rerun your code to see if the error still occurs. Sometimes, we override variables when testing out code, so this is a good first check to ensure we really have an error or not.
- Next, I open the script and load in the data needed.
- Then, I run the script line by line until the error occurs.
- Sometimes, I luck out and know the error message, but most times that’s not the case. I start by stating the goal of the line. What is the purpose of the function? What sort of outcome do I expect (very important if you have no error but are getting unexpected values)? Stating the objective will help you focus on the problem at hand.
- Once I know the goal, I figure out what I need to reach that goal. Maybe the function selected was not the right function to use (typical when we have unexpected results instead of error messages).
- If the function selection is correct, I then move on to the inputs. What goes into the function (do a help on the function)? Am I providing all the parameters? Maybe I’m missing an input?
- Once I know I’m providing all the right input, I check to see if the input is correct. That is, I’ll print out the values in each input or plot them or use the summary command. The goal is to make sure the input is realistic.
- If the input is NOT realistic, then I go to where I create that input and check the code there. Usually, I’ll have one little mistake; like missing an index or I didn’t convert to numeric values. Generally speaking, this is the type of error I see the most.
- If the input looks realistic, then my next step is usually to google the error message. You can read more about how to google coding problems in the next section.
- At this point, I either have fixed the problem or I’m stumped. If I’m stumped, it’s probably time to reach out for help; either to peers, mentor, instructor, or online (Stack Overflow is a great website to post coding questions).
- Now I should have a solution. The next step is to fix the code and then clear out my environment again. I rerun each line of code and see if the error is fixed. If I have a new error, then I go through the process again. Otherwise, my code is fixed and I can move on.
Again, the steps presented here are not meant to be the holy grail of debugging, but instead are meant to help guide you through the process. What works for you will be different from what works for me or your peers. Refining this process will only make you a better coder.
Google It!
Googling is an important step in the debugging process. But googling efficiently is a challenge. If done correctly, you’ll land on the perfect result instantly. Done poorly, and well, you’ll be sifting through hundreds of pages before coming to the right answer.
As you debug more and more code, and thus google more and more errors, you’ll become more efficient (e.g., you’ll know what gets you to the answer quicker and what doesn’t). For me, I have more luck then expected by simply copying the error output and pasting it directly in the google search bar and adding ‘in R’ to the search. If this doesn’t work, my next search is usually the function name + ‘error in R’. I’ll have to look through a couple stack overflow pages, but this usually does the trick.
Searching to find a function can be a bit more tricky. Finding the right phrase to describe the function you need is important. I usually start by googling a broad idea with the phrase ‘in R’ attached. Then after looking through a few pages I start to see a more common phrase and I’ll google that instead, again with ‘in R’ attached. I’ll usually find some functions at this point that let me do what I wanted. I then search for examples of these functions to see how I should set up my code.
There are some great links in the resources that discuss best practices for googling. Similar to your debugging process, your googling process will be unique and probably change over time.
Quiz Yourself...
Before we work through some examples, let me introduce you to the DataCamp setup. Although you've seen DataCamp examples before, we will be using it here in a 'quiz mode'. You'll run the code, but an error will pop up. Your task is to fix the code so the error message goes away. You can change and rerun the code as much as you want. If you are having trouble or need a little extra guidance, click the 'Hint' button. Let's give it a try. Run the code below without changing anything.
You should have gotten the following error: "Your code contains a syntax error". If you look in the console, you'll see the error is specifically at line 2 (where you assign "a") and the specific error is a parsing error. Do you know why the error is occurring? Try fixing the code and rerunning. Did you get the right answer now? If not, try clicking on the 'Hint' button. Now fix the code again, and see if you get the right answer. If you are still stuck, you can always click the 'Solution' button to see what 'a' should be assigned to.
Now that you've seen how DataCamp can help you practice your debugging skills, take a look at the coding examples below. Each has a unique error. Your task is to find the error and fix the code. You can try as many times as you want. All examples will use 36 years of monthly temperature data from NYC. There are two variables: Date and Temperature. The variable Date is a date object while the variable Temperature contains the temperature data in degrees Celsius.
For the first example, estimate the 36-year mean for the month of August. There is one error in the code:
For the second example, I've estimated the 36-year mean for each season (DJF, MAM, JJA, and SON). The results are saved to the variable seasonMean. I want to replace the DJF estimate with an NA. Again, there is one error in the code:
For the third example, plot a time series of monthly temperature for NYC from 2000-2010. There is one error in the code:
Explore Further...
I highly suggest you check out the resources listed below. Seeing how other people debug is of great use. There are some great tutorials, specific to R, and some more broader views on how to debug in general. I encourage you to take some time now and read through the material.
Advanced R (Debugging) by Hadley Wickham
Exceptions Debugging (Advanced R by Hadley Wickham)
R Debugging Tutorial (video)