Debugging means finding a cause, not trying random fixes.
Writing code is one task. Running it shows what it actually does. Debugging begins when that behavior is unexpected: reproduce the problem, observe clues, find a cause, make a small fix, and verify the result.
Reproduce → Observe → Find the cause → Fix → Verify
1. Run the same input that shows the problem.
2. Read the error message or compare the actual result with the expected result.
3. Form a small hypothesis and inspect the relevant line or value.
4. Change only what is needed.
5. Run the program again and check for new problems.For example, if a price is too high, do not immediately rewrite the whole calculation. First reproduce it with the same price and discount, observe the intermediate values, then check the formula that created the unexpected result.
A useful debugger changes one idea at a time. That makes it easier to tell whether a change solved the real cause or only hid a symptom.
Start with evidence: An error message, a traceback, a surprising result, and a variable value are clues. Each clue narrows the part of the program worth investigating.
# Syntax error
if cena > 100
print("Skupo")
# Runtime error
cena = 100
kolicina = 0
print(cena / kolicina)
# Logic error
cena = 100
popust = 20
nova_cena = cena + cena * popust / 100
print(nova_cena)The first example has a SyntaxError because the if line needs a colon. The second raises ZeroDivisionError while running. The third program runs, but adding a discount makes the price higher: that is a logic error, so there may be no traceback at all.
Traceback (most recent call last):
File "main.py", line 5, in <module>
rezultat = 100 / 0
ZeroDivisionError: division by zeroTraceback (most recent call last) introduces the call history. The file name and line number show where Python noticed the exception. The final line names the exception and its message. In a larger program, an earlier stack frame may contain the decision that caused the bad value, so the traceback is a useful clue rather than a complete explanation.
cena = 200
popust = 10
iznos_popusta = cena * popust
print("DEBUG:", iznos_popusta)
nova_cena = cena - iznos_popusta
print(nova_cena)
# Correct calculation:
iznos_popusta = cena * popust / 100The temporary DEBUG print reveals that the discount amount is 2000 instead of 20. Dividing the percentage by 100 fixes the formula. Remove temporary DEBUG prints after the investigation so they do not become confusing output later.
1. Open the Python file and choose the correct interpreter.
2. Click left of a line number to add a breakpoint.
3. Start Run and Debug or press F5.
4. If asked, choose Python File debugging with the Python extension installed.
5. The program stops before it executes the breakpoint line.A breakpoint pauses the program at a chosen place so you can inspect its state. VS Code layouts and keyboard shortcuts can differ by operating system or settings, so the debugger toolbar buttons are always a good alternative.
def cena_sa_popustom(cena: float, popust: float) -> float:
iznos_popusta = cena * popust / 100
nova_cena = cena - iznos_popusta
return nova_cena
print(cena_sa_popustom(200, 10))Put a breakpoint on the first line inside the function. In the Variables panel, first inspect cena and popust. Step Over executes one line without entering a called function; Step Into enters one when possible; Step Out continues until the current function returns; Continue runs to the next stop. Watch how iznos_popusta and nova_cena appear as execution moves forward.
A practical debugging strategy
- 1. Repeat the problemUse the same input or action that shows the error. A problem you cannot reproduce is harder to investigate.
- 2. Read the clueRead the traceback, error type, or actual result carefully. For a logic error, write down what result you expected instead.
- 3. Form a hypothesisAsk one focused question, such as “Is kolicina zero here?” or “Did I use a percentage as a whole number?”
- 4. Inspect the program stateAdd a temporary
print()or stop at a breakpoint. Check values and the order in which lines run. - 5. Make one focused change and verify itRun the same scenario again. Confirm both that the original problem is fixed and that the change did not create a new one.
Debugging habits to avoid
- Changing many lines at onceSeveral changes can hide which one helped or introduced a new error. Keep each experiment small.
- Reading only the last word of an errorThe exception type, file, line number, and surrounding code each add useful context.
- Leaving debugging output in the final programTemporary prints are useful while investigating, but remove them or replace them with deliberate program output afterward.
