Loading...
Use debugging tools to test an explanation of a fault. A breakpoint and a small failing input can reveal the state transition that differs from the algorithm’s intended invariant.
What you'll be able to do
An IDE combines facilities such as editing, syntax highlighting, diagnostics, execution and debugging. Auto-completion can reduce typing mistakes but cannot establish that the algorithm meets the requirements. Syntax faults violate language structure; runtime faults arise during execution; logical faults can produce wrong results despite syntactically valid execution.
Start with an observed failure, a reproducible input and an expected result. Reduce an unnecessarily large case to one that still exposes the problem. A test that asserts an expected output can detect a regression, while the debugger helps inspect how the current state arose. These are complementary activities rather than rival ways to prove every program correct.
A breakpoint pauses at a chosen line or condition. Watches show selected expressions and variables; the call stack identifies active routine calls. Step into follows a called routine, step over executes it without entering its internal detail, and step out continues until the current routine returns. Exact controls vary by tool, so focus on their execution meaning.
For binary search, watch low, high and mid and confirm that every unsuccessful iteration reduces the candidate interval. With low=0, high=1 and mid=0, setting low=mid after a too-small item leaves low unchanged. A breakpoint on the next iteration reveals the repeated state. The suitable update for this inclusive-bound algorithm is low=mid+1.
Changing a limit just until one test passes can hide a different boundary error. Explain the invariant, such as all remaining possible positions lying within low through high, and show that the update both preserves it and makes progress. A missing value in a two-item array is a useful small case for this non-progress fault.
After correction, check an empty array, one item, a target at either end and an absent target before and after the range. Inspect exception context instead of broadly suppressing every error. Logs can help with intermittent behaviour that is difficult to pause, while watches and stepping suit a controlled local trace. Retain evidence that connects the original fault, the reasoned change and the observed result.
| Trace point | low | high | mid | Explanation |
|---|---|---|---|---|
| First iteration | 0 | 1 | 0 | Item at mid is below target |
| Faulty update low=mid | 0 | 1 | 0 | Candidate interval does not shrink |
| Correct update low=mid+1 | 1 | 1 | Recomputed next iteration | The rejected midpoint is excluded |
Attempt the task before opening its worked response. Record each change of state, explain the rule used, and check the result against the original requirements. Code examples labelled Python 3 use that language’s conventions; pseudocode states its own assumptions.
Common mistakes to avoid
Key takeaways
Test yourself
Answer a few questions, then review anything you missed.
Start with the quiz above to check the key ideas. You can also choose another topic from the practice library.