reveal.js

# Debugging

---

CS 65 // 2021-03-18

## Administrivia
- Exam 2 deadline is extended to Tuesday, 3/23
- 
 Check in

# Questions
## ...about anything?

# Review

## Lists
- What is a list?
    + Sequence of things (numbers, strings, mixture)
- 
 How can I create a list in Python?
    + `t = [100, 200, "abc"]`
- 
 What operations do lists support?
    + `+` (concatenate), join a list of words, `append`, `pop`
- 
 Lists are "mutable." What does that mean?

# Self Checks

# List Exercises

# Debugging

## Debugging
- We often refer to an error in our code as a "bug" and the act of finding and fixing the error as "debugging"
- 
 This terminology is commonly attributed to **Admiral Grace Hopper**
    + 
 In 1940, she was working at Harvard on an old computer, but it wasn't working
    + 
 Her colleagues discovered a **moth** stuck in the circuitry of the computer
    + 
 Hopper apparently remarked that they "debugged" the computer

## Debugging Strategies
- Suppose that your code isn't working
- 
 **Questions:**
    + 
 What is your usual approach for fixing errors?
    + 
 Were their insightful techniques from the reading?

---

- 
 **THINK:** Write down your thoughts
- 
 **PAIR:** Share your thoughts in a breakout session
- 
 **SHARE:** Afterwards, we'll discuss as a large group

## Debugging Strategies
- Use the error printed to find the exact line and look at it closely
- Putting print statements throughout the code
- Breaking down functions into smaller, less complex functions
- Looking at examples, reviewing material, etc.

## Debugging Strategies
- Commenting out certain pieces of code so that you can "narrow in" on a piece of code that you're looking at

## A Suggested Approach
1. **Identify** that an error exists
    - Syntax error, runtime error, semantic error
2. 
 **Find** the line (or lines) of code responsible
3. 
 **Understand** the offending code
    - What is it **currently** doing?
    - What should it **actually** be doing?
4. 
 **Fix** the code

## Scientific Debugging
- After we notice a bug, **finding**, **understanding**, and **fixing** it can be non-trivial
- 
 Think of debugging as a **scientific process** 
    + 
 Make a *hypothesis* to what is causing the error
    + 
 *Test* your hypothesis by inspecting the code / execution around the area you've identified
    + 
 If your hypothesis is wrong, make another hypothesis and keep testing

## Scientific Debugging
- Do **NOT** make random minor changes, rerun your code, and hope for the best!
- 
 **DO** make careful, considered, changes that test your hypothesis in some way

## Unit Testing
- Write one **unit** of code (e.g. an expression) at a time and test it before moving on
    + 
 The shell is a great place to do this!
- 
 Writing 100 lines of code, running it, and noticing it doesn't work is a bad strategy
    + 
 Usually many bugs will be present and it will be hard to find source of errors

# Debuggers

## Debuggers
- Software tools exist, called **debuggers**, that help us investigate what is happening in our programs
- 
 Good debuggers have the following features:
    + 
 **Inspect** the values of variables
    + 
 Set and remove **breakpoints** where your program will “pause” for inspection
    + 
 **Advance** through program line by line, or to the next breakpoint, or skip over subroutines
    + 
 Show you the **stack frames** of all your function calls and navigate up and down the stack

# Thonny's Debugger

## Exercise
- Suppose I'd like to write two filtering functions:
    + `extract_even(lst)` returns all the elements with indices, 0, 2, 4, ...
    + `extract_odd(lst)` returns all the elements with indices, 1, 3, 5, ...
- 
 If we run these functions we should get:
    ```py
    >>> lst = ["abc", "def", 100, 200]
    >>> extract_even(lst)
    ["abc", 100]
    >>> extract_odd(lst)
    ["def", 200]
    ```