Debug loops by writing the state, not by staring

Loop bugs often feel invisible because your eyes read the code the way you intended it, not the way it runs.

Use this post as a small study note for making better decisions while solving, not as a quick definition dump. Read the idea, pause at the example and try to move one line forward yourself, then use the checklist on a real problem.

The main idea

Track the variables that change on each iteration. Stop after three or four rows and compare the table with the expected pattern.

The important part is not memorizing the method; it is noticing what calls the method into action. Which expression, diagram, unit, variable, or code behavior made this approach the right one? If you can name that trigger, a similar problem becomes much less stressful.

A short example

For a counter loop, writei, the condition result, and the value changed inside the loop.

How to approach it step by step

1. Write the givens cleanly and fix units, symbols, or variable names before calculating.
2. Identify the intermediate fact you need before trying to jump directly to the answer.
3. After each line, run a small check: do the units match, is the sign correct, is indentation or scope correct in code?
4. When you get an answer, return to the original question and check that it answers exactly what was asked.

Check while you solve

• Write the first value before the loop body runs.
• Check whether the end value is included.
• Track only variables that can change.

The common mistake

If the table and your mental model disagree, trust the table.

The practical way to catch this mistake is to check the decision points, not only the final answer. Ask questions like: Why this formula? Why this component? Why this loop condition? That makes the answer stronger in content, not just in arithmetic.