# Debugging Logic and State

Computer Science I · Programming I · https://tryals.app/learn/computer-science-i/debugging-logic-and-state

## Hunting the Bug

A **bug** is a mismatch between what a program does and what it should do. **Debugging** is the disciplined process of locating and fixing that mismatch by searching through the program's **state**—the current values of its variables—for the point where things first go wrong.

Effective debugging relies on two everyday tools:

| Tool | Mechanism | Purpose |
| --- | --- | --- |
| **Print debugging** | Inserting statements showing variable values | Crude but effective visibility |
| **Debugger** | Setting breakpoints and stepping through | Precise state inspection |

Both tools serve the same goal: making the invisible state **visible** so you can see where it diverges from your expectations.

## The Debugging Routine

A reliable routine prevents wasted time and blind guessing:

1. **Reproduce**: Find an input that triggers the bug consistently. Unreproducible bugs cannot be reliably fixed.
2. **Localize**: Narrow down **where** the state first becomes wrong. Confirm correct state early and squeeze the gap.
3. **Understand**: Determine why that specific line produces the wrong value. Do not fix blindly.
4. **Fix and verify**: Change the code and re-run your tests to confirm the fix works without breaking anything else.

The golden rule is to **reason from evidence, not assumption**. 

> **Pitfall:** Changing code randomly hoping the bug disappears ("shotgun debugging"). Without observing actual state, you cannot know if you fixed the real cause.

## Practice questions

5 of this lesson's 11 practice questions, with answers. The full set is in the app.

### 1. A bug appears only in production, never locally, and disappears when logging is added. What class of bug does that pattern suggest?

A. A random hardware fault, since software is deterministic
B. A syntax error that the production compiler catches differently
C. A bug in the logging library rather than the application
D. One depending on timing or environment, which logging perturbs

**Answer:** D. One depending on timing or environment, which logging perturbs

**Why:** Logging perturbs timing and memory layout, so a bug that vanishes when observed is almost always a race, an uninitialised read, or an environment difference. They are called heisenbugs for that reason, and the useful response is to look for shared mutable state and configuration drift rather than to keep adding print statements.

Page: https://tryals.app/practice/computer-science-i/debugging-logic-and-state/a-bug-appears-only-in-production-never-locally-and-disappears-when

### 2. Select every practice that the lesson recommends for debugging.

A. Change code randomly until the symptom disappears
B. Narrow down where the state first becomes wrong
C. Observe the actual values variables hold
D. Reproduce the bug before trying to fix it
E. Re-run the test suite after the fix to confirm nothing else broke

**Answer:** B. Narrow down where the state first becomes wrong; C. Observe the actual values variables hold; D. Reproduce the bug before trying to fix it; E. Re-run the test suite after the fix to confirm nothing else broke

**Why:** Reproduce, observe, localize, and re-run after fixing are the recommended routine. Changing code randomly is 'shotgun debugging', the pitfall the lesson warns against, because it can hide a symptom without addressing the real cause.

Page: https://tryals.app/practice/computer-science-i/debugging-logic-and-state/select-every-practice-that-the-lesson-recommends-for-debugging

### 3. Order the steps of the disciplined debugging routine.

**Answer:**

1. Reproduce the bug with an input that triggers it every time
2. Halve the region between a good point and a bad one, repeatedly
3. Understand why that line produces the wrong value
4. Fix the code and re-run the reproducing case and the rest of the suite

**Why:** Reproduce, localize, understand, then fix and verify. Reproducing first is essential: without a reliable trigger you cannot tell whether a later change actually fixed anything. Fixing before understanding is 'shotgun debugging', the pitfall this lesson names.

Page: https://tryals.app/practice/computer-science-i/debugging-logic-and-state/order-the-steps-of-the-disciplined-debugging-routine

### 4. Systematic debugging narrows down where the state first becomes wrong, rather than reading the code looking for the mistake. Why is bisecting the execution more reliable than inspecting the source?

A. Because source code is often obfuscated and hard to read accurately.
B. Because bugs are usually in library code rather than in the code being read.
C. Because bisecting is faster, though less reliable than careful reading.
D. Because a bug is where your reading was wrong, so re-reading repeats it.

**Answer:** D. Because a bug is where your reading was wrong, so re-reading repeats it.

**Why:** You wrote the code believing it correct, so your reading already contains the error and re-reading begins from the same misunderstanding, which is why the bug is often obvious to someone else immediately. Checking actual state removes belief from the process, and each check halves the region. `git bisect` applies the identical logic to history.

Page: https://tryals.app/practice/computer-science-i/debugging-logic-and-state/systematic-debugging-narrows-down-where-the-state-first-becomes

### 5. Sort each debugging action by whether it reasons from evidence or merely guesses.

**Answer:**

- Reasoning from evidence: Print the variable's value at the suspect line, Set a breakpoint and step through, watching the state
- Debugging by guessing: Change a comparison because it feels wrong, then re-run, Rewrite the function from scratch and hope the bug vanishes

**Why:** Printing values, stepping through, and narrowing the good-to-bad gap all produce evidence; changing code on a hunch, rewriting blindly, and adding delays produce none. The danger of the guessing moves is that they can hide a symptom while leaving the real cause in place.

Page: https://tryals.app/practice/computer-science-i/debugging-logic-and-state/sort-each-debugging-action-by-whether-it-reasons-from-evidence-or