5. Debug

"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan in "The Elements of Programming Style" (1974)

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian Kernighan in "Unix for Beginners" (1979)

"Hercule Poirot's methods are his own. Order and method, and 'the little grey cells'." - The Big Four, in Agatha Christie

"Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." - Sherlock Holmes, in Doyle Arthur Conan

"Debugging is like being the detective in a crime movie where you are also the murderer." - Filipe Fortes

"By June 1949 people had begun to realize that it was not so easy to get programs right as at one time appeared. ... the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs." - Maurice Wilkes

1. How to avoid debugging?

1. Test Driven Development - write tests in the Reinterpret the Problem phase (e.g. using assert)
2. Use the incremental development method

2. How debug should not look like?

1. Making random guessing and trying it out
2. Staring on the code until an insight will appear
3. Copy-paste of the error message to a search engine without thinking
4. Asking someone else

2. Challenge - Three models

1. Problem - What is the code supposed to do?
2. Program (Python) - What is the code actually doing?
3. Programmer - What do I think that the code is doing? (expectations, the mental model of the program)

3. Fundamental Mindset - The Scientific Method - "Experimental" / "Detective" / "Doctor"

• Debugging systematically
• Everyone is a suspect (Except Python)

Terminology (IEEE 610.12-1990)

1. Failure - occurs when a program’s output does not match documented output requirements, or the programmer’s mental model of output requirements.
2. Fault - which is a runtime state of a program that either is or appears to be incorrect (as in assuming a lack of output from a debugging print statement to mean the code was not reached). Faults occur as a result of errors.
3. Error - which are program fragments that do not comply with documented program specifications or the programmer’s mental model of specifications (such as a missing increment or misspelled variable name).

The Four Questions to Answer

1. What is the bug?
2. Why the bug happens? What is the cause to the bug? What is the root cause?
3. Where in the code does the cause of the bug lay?
4. What-if I change the code like that...?

Where to Look for Bugs Especially?

1. In the main algorithm section
2. In the gap between code sections

Empirical Approach for Debugging

1. Reproduce (What?)

2. Diagnose (Why? Where?)

   1. Collect Clues

      1. The Bug Itself
         1. Input/Output
         2. Error messages & Traceback
            1. Meaning
            2. Examples
            3. What might cause this error
            4. How to uncover the root cause
      2. Reading the Code (with a critical eye)
      3. Results from the Test phase
      4. Debugging Toolbox

   2. Model the Cause(s) of the Bug

      1. Formulate Hypothesis
      2. Manipulate / Check
      3. Accept / Reject
      4. Keep Records

   3. Use Binary Search

3. Fix (What-if?)

4. Repeat until you fix the bug

5. Reflect - Debug yourself

Toolbox

1. print (to open the blackbox)
2. Comment in/out
3. Debugger

Rubber Duck Debugging

• Tackling the Mental Model
• Socratic Ducking

Two Great Resources from "How to Think Like a Computer Scientist" Interactive Book:

1. Debugging Interlude
2. Appendix - Debugging

Checkout Question:

Did I fix the Bugs?