2.2.1 - IDE tools and systematic debugging

IDE tools connect editing to feedback

An integrated development environment, or IDE, combines tools used to write, run and inspect source. Its source editor may provide syntax highlighting, indentation, autocomplete and error diagnostics; its execution tools may include a compiler or interpreter, output console and debugger. An editor's colouring does not execute a program or establish that its logic is correct.

Syntax highlighting distinguishes tokens such as keywords, string literals and comments. An unexpectedly coloured section can draw attention to an unclosed quote. Autocomplete suggests a recognised name or signature, reducing typing mistakes. Both assist the programmer; a correctly spelled but wrong variable can still be accepted. Automatic indentation helps show nesting, but a block placed at the wrong level can remain legal.

Diagnostics report detected problems with messages and locations. Python's interpreter can report SyntaxError, a runtime exception and its traceback; an IDE may also inspect the code before execution. A highlighted line is a starting point for investigation. A missing bracket on one line may only become impossible to parse at the next line, so inspect nearby code and the actual message.

In a local IDE, save the source, choose the appropriate Python interpreter, run the program and read the console. For debugging, launch through its debugger and inspect the paused state. Exact buttons depend on the IDE. The course's Python console runner permits execution and output; it does not provide a proved breakpoint/watch interface. Practise those tools in a suitable local IDE using these small original programs.

Syntax, runtime and logic faults need different evidence

A syntax fault breaks the language's grammar. A runtime fault occurs while executing a syntactically valid operation. A logic fault produces unintended behaviour without necessarily causing an exception. Classify the actual failure before choosing a debugging tool.

if score >= 10
    print("Pass")

The missing colon prevents Python from parsing this statement. The program cannot reach an ordinary breakpoint until syntax errors are repaired. A diagnostic helps locate the malformed statement.

def average(total, count):
    return total / count

average(12, 3) returns 4.0, but average(0, 0) raises ZeroDivisionError. Grammar is valid; the failure depends on the input. Inspect count at the failing call and agree the required behaviour for no records before changing the code. Returning zero is only correct if the contract defines that case.

A misspelled name can also be a runtime fault rather than a syntax fault. This source follows Python's grammar, but the final statement tries to read a variable that was never defined:

total = 6
print(totl)

Execution raises NameError for totl. Correcting the name to total displays 6. A breakpoint or traceback can show where the invalid name is used; the decisive distinction is accepted grammar followed by a failing operation, not simply that a spelling mistake occurred.

def ticket_price(age):
    if age > 16:
        return 8
    return 5

Suppose the requirement is that ages 16 and over pay 8. Age 16 returns 5 without an exception: a logic fault in the boundary comparison. Changing > to >= fixes that stated condition. A runtime message cannot report every mismatch between source and a requirement. Expected results and a deliberate boundary test are needed.

Breakpoints and watches expose the state at a decision

A breakpoint pauses execution at a chosen source location so the programmer can inspect current state. In the examples here, a breakpoint pauses immediately before the highlighted line executes. A watch displays a chosen variable or expression as execution progresses. A locals window shows variables in the selected stack frame; it should not be confused with a complete history of earlier values.

The function should count all non-negative readings, including zero, but contains a deliberate fault:

def count_nonnegative(values):
    count = 0
    for value in values:
        if value > 0:
            count += 1
    return count

For [2, 0, -3], expected count is 2 but actual count is 1. Set a breakpoint on if value > 0: and watch value and count. The pauses occur before the comparison:

At the second pause, value is 0. Stepping over the comparison skips the increment, exposing the first mismatch with the requirement. The watch identifies a state; reasoning about the specified condition identifies the repair, value >= 0.

A conditional breakpoint can pause only when an expression is true, for example value == 0; this avoids inspecting hundreds of irrelevant iterations. It depends on the IDE's support. Put a breakpoint before the operation that may corrupt state, rather than only inspecting the incorrect final result. Avoid watch expressions with side effects: calling a method which changes a list may alter the program being investigated.