Debugging Guide

Bugs are a natural, and completed expected part of programming! Writing bug free code is nearly impossible on the first try, so building the skill of debugging your programs will be essential for being a successful program. Unfortunately, approaching each bug is sometimes its own unique challenge, but there are some common strategies for resolving problems that you can practice as you build your debugging skills. In particular, this guide focuses on how to interpret error messages and how to find where the bug in your program might be.

Chapter 1: Understanding the Pre-Written Code in the Notebook¶

Most of our assignments start with some pre-written code. It is really important for you to understand what is happening at each step of the notebook. Even for the portions where we have pre-written code, you shouldn’t run it without first understanding what it is doing (unless it says you can ignore that code). We suggest the following three ways to understand it:

• Be sure to read all the text in the handout (the notebook file you are writing your code it). We wrote the text in order to give students detailed context about what is happening.
• Read through each cell of code. For each cell, write down 1-2 sentences in English (can also be a comment in the file itself) describing what it is doing. For each function, write down what it does, what the inputs are, and what the outputs are. For each new variable name that is created in the cell, write down in English what that variable name represents.
• Print each of the new variable names in the cell, and ensure it is doing what you think it is doing. Sometimes, printing a whole dataframe or array is best to check your understanding. Other times, printing the shape of a dataframe or array print(variable_name.shape) is best for checking your understanding. Other times, printing the columns of a dataframe print(dataframe_name.columns) will be best.

Chapter 2: Understanding Error Messages¶

It is important to understand the structure of an error message so that you don’t get overwhelmed. The first part of the error is the traceback. The traceback TRACES the line in the file where the error occurred, and stacks the errors in every file involved in the order that files are referenced. The very first file is the file you just edited, your file. The file below that is some other random python package file, depending on what package you are using in your code. Then the file after that is probably another random package file. You only need to worry about fixing YOUR file. The second part of the error is the error name. This is ALL THE WAY AT THE BOTTOM and it tells you what you did wrong.

For example here, I made a mistake on line 7 of MY FILE. So, I scroll down all the way to the bottom and see that it says “x and y must be the same size”. So I scroll back up to line 7 to fix this. Nothing else matters because all the other files shown to me are things in the python plotting package and it’s just freaking out at me because I didn’t make my x and y the same size.

Common Errors¶

NameError: name ‘something’ is not defined

This means that the variable in the quotes was not defined, you didn’t declare it and set it equal to something prior. Maybe you misspelled the variable name or you just never declared it.

This sometimes happens if you run your code out of order. Our Jupyter notebooks are designed to run sequentially; from top-to-bottom. However, Jupyter allows you to run cells out-of-order. This can result in errors where variables are not defined, or variables have been reassigned and no longer have the expected columns. To avoid such errors, we recommend you always Run All instead of running individual cells.

ValueError: y_true and y_pred have different number outputs (39!=1)

If two variables have different number outputs that means that the size of whatever those variables store is different, but whatever function you are using them in requires them to be the same. You can print them out to see the size difference and think about why one is smaller than the other. For example, print(y_true.shape, y_pred.shape)

ValueError: Expected 2D array, got scalar array instead

The function that is taking in your data needs a two-dimensional matrix, but you seemed to have given it something less than 2 dimensions.

AttributeError: ‘tuple’ object has no attribute ‘fit’

An attribute error happens when you are trying to do something with a datatype that the datatype just wasn’t made to do. In this case, a tuple object has no function call “fit()”.

In general, it is good practice to print out the datatype that results in the error, because it might not be what you think it is. If your error message is accusing your model of being a tuple object, you might not have a model object due to some syntax error, so print it out and see. Maybe you are certain that your undefined variable name is defined. Use control f and see for yourself. Also, you can look up the documentation for a specific function if that function is involved in the error, to read about what that function needs as input to understand why your input doesn’t work.

Further Notes:¶

Don’t be afraid to struggle through for a bit and also to reach out for help when you can’t solve! Debugging can be frustrating, but it is an expected part of the process so productively struggling for a bit will help you become a better programmer.

Try to understand the code by yourself first for some time. If you don’t get it, take a break! Take a walk, stretch, workout, relax, take a nap or do anything else. Then get back with it with a fresher mind. This almost always helps when it comes to coding. Further, don’t be afraid to try to write some code and get an error. Even the most experienced programmers try code out, see if it works, and if it doesn’t work they use the error message to help them debug.

Struggle is a part of the process, so you should not lose confidence when struggling. If you are stuck for more than 1-3 hours on something, reach out to the staff! We will be happy to help!