Grade by Grade
C. Computer Environments and Systems · Computer Environments and Systems

The Integrated Development Environment: Editor, Translator and Debugger

C3.1 C3.2About 70 minutes
Learning goals
  • I can name the main parts of an IDE (source code editor, interpreter or compiler, shell or console, debugger) and explain what each does.
  • I can use editor features such as syntax highlighting, auto-indent and error underlining to write code faster and with fewer mistakes.
  • I can use a debugger to set a breakpoint, step through code and watch variables to find a logic error.
  • I can find help inside my IDE on my own.

Words to know

IDE (integrated development environment)
One program that combines the tools for writing, running and debugging code.
source code editor
The part of the IDE where you type code, with features such as syntax highlighting, line numbers and auto-indent.
syntax highlighting
Colouring keywords, strings, numbers and comments differently so code is easier to read and mistakes stand out.
shell / console
The panel where the program's output appears, input is typed, error messages are shown, and single lines can be tried.
debugger
A tool that runs a program under your control so you can pause it, step through it and inspect variables.
breakpoint
A marked line where the debugger pauses the program before running that line.
step over / step into / step out
Debugger commands: run the next line (treating a function call as one step), go inside a function call, or finish the current function and return.
watch (variables panel)
A list showing the current values of variables while the program is paused.

One tool to write, run and fix code

Early programmers wrote code in one program, translated it with another, and looked for bugs by printing pages of numbers. Today you can do all of it in one window: an integrated development environment, or IDE.

Python comes with a simple IDE called IDLE. Thonny is a free IDE designed for beginners, with a very clear debugger. Visual Studio Code (with the Python extension) and PyCharm are popular with professionals, and browser-based editors let you code on a Chromebook. They look different, but they share the same main parts. Once you know the parts, you can learn any IDE quickly.

Remember from Grade 9

In Grade 9 math you ran and changed short programs (often in Python), perhaps in a browser editor. Every editor you used had at least two of the parts in this lesson: a place to type code and a place where output appears.

The main parts of an IDE

  • Source code editor. Where you type. Look for syntax highlighting (keywords, strings and comments in different colours), line numbers (error messages refer to them), auto-indent (important in Python, where indentation is part of the syntax), bracket matching, auto-completion (suggests names as you type) and error underlining (marks some mistakes before you run).
  • Translator: interpreter or compiler. The Run button hands your source code to the language's translator. For Python this is the Python interpreter; for languages such as C++ it is a compiler. The lesson Interpreters and Compilers explains the difference.
  • Shell or console. Shows output and error messages (with the line number), takes keyboard input, and in Python lets you try one line at a time at the >>> prompt.
  • Debugger. Lets you pause a running program at a breakpoint, step through it line by line, and watch variables change.
  • Other helpers: a file or project browser, built-in help and documentation, a search-and-replace tool, and often a formatter or linter that checks style.
▶ Run🐞 DebugStep overStep intoStep out■ Stoptoolbar1def average(marks):2 total = 03 for i in range(1, len(marks)):4 total = total + marks[i]5 return total / len(marks)67print(average([80, 90, 70]))Editor: line numbers, colours, auto-indentVariables (watch)marks[80, 90, 70]total0i1values right now,paused at line 4Shell / console (output and errors)>>> %Run average.py53.333333333333336>>> %Debug average.py (paused at line 4)
A typical IDE layout (simplified). The program is paused at the breakpoint on line 4 (the dot in the margin), the highlighted line is about to run, and the variables panel shows the values right now. The shell shows the earlier normal run's wrong answer.

Debugging: watching a program think

In the Software Development unit you will learn to test and debug with tracing and print statements. A debugger does the tracing for you.

  1. Set a breakpoint by clicking in the margin next to a line number (or pressing the IDE's breakpoint key).
  2. Start debugging (the bug-shaped button, or Debug → Start). The program runs until it reaches the breakpoint, then pauses before that line runs.
  3. Step through the code. Step over runs the next line; if the line calls a function, the whole call runs as one step. Step into goes inside the function call so you can follow it line by line. Step out finishes the current function and pauses back where it was called.
  4. Watch the variables panel after each step. The moment a value is not what you expected, you have found your bug.
  5. Continue runs to the next breakpoint, and Stop ends the session.

(Python also has a built-in text debugger: putting breakpoint() on a line pauses there in the console.)

main programx = 5y = double(x)print(y)functiondef double(n): return n * 2Step intoStep over: the whole call is one stepStep out: finish the functionand return to the caller
Step into follows the call into the function; step over treats y = double(x) as one step; step out finishes the function and returns to the line that called it.
def average(marks):
total = 0
for i in range(1, len(marks)):
total = total + marks[i]
return total / len(marks)
print(average([80, 90, 70]))

This program should print the average of 80, 90 and 70, which is 80.0. It has a logic error: it runs without crashing but gives the wrong answer. Output: 53.333333333333336

Worked example

Example 1: Find the bug with the debugger

Use a breakpoint and the variables panel to find the logic error in the program above.

  1. Set a breakpoint on line 4, total = total + marks[i], and start debugging. The program pauses there the first time the loop runs.
  2. The variables panel shows marks = [80, 90, 70], total = 0 and i = 1. Lists start at index 0, so i should be 0 on the first pass. That is suspicious already.
  3. Step over once: total becomes 90 (marks[1]). Continue to the next pause: i = 2, and stepping gives total = 160. The loop then ends: marks[0] = 80 was never added.
  4. The cause is range(1, len(marks)), which starts at 1. Change it to range(len(marks)). Run again: the output is 80.0.

The loop skipped index 0 because of range(1, ...). With range(len(marks)) the program prints 80.0.

def average(marks):
total = 0
for i in range(len(marks)):
total = total + marks[i]
return total / len(marks)
print(average([80, 90, 70]))

The fixed program. Output: 80.0

Worked example

Example 2: Let the editor help you

A student types this in an IDE:

  1. def greet(name)
  2.     print("Hi, " + name)
  3. greet("Noor")

What will the editor and the shell show, and how should the student fix it?

  1. Many editors underline the end of line 1 in red before you even run, because a def line must end with a colon.
  2. If the student runs it anyway, the shell shows a SyntaxError pointing at line 1 (Python's message says it expected ':'), and nothing is printed, because Python checks the whole file's syntax before running any of it.
  3. Fix: def greet(name):. When the colon is typed, the editor's auto-indent moves the next line in by 4 spaces automatically. The program then prints Hi, Noor.

A SyntaxError on line 1 (missing colon). Add the colon and the program prints Hi, Noor.

Just for fun

In 1947, operators of the Harvard Mark II computer found a real moth stuck in one of its relays and taped it into their logbook with the note "First actual case of bug being found." Engineers had already been calling problems "bugs" for years, but this one made a great story, and the logbook page is now in the Smithsonian's collection.

Hands-on activity

Debugger safari

You need: a computer with Python and an IDE that has a visual debugger. Thonny (free, thonny.org) is a good choice; VS Code with the Python extension also works. IDLE has a simpler debugger (Debug → Debugger in the shell window).

  1. Find each IDE part from this lesson in your IDE: editor, line numbers, run button, shell, debugger buttons, variables panel. Sketch the window and label them.
  2. Type the buggy average program. Set a breakpoint on line 4 and debug it as in Example 1. Write down i and total after each step in a table.
  3. Fix the bug and confirm the output is 80.0.
  4. Try step into with this program and watch the debugger go inside double:

def double(n): / return n * 2 / x = 5 / y = double(x) / print(y)

  1. Use your IDE's Help menu (or its documentation website) to find the keyboard shortcuts for Run, Step over and Step into. Write them down.

What to look for: a labelled sketch, a correct trace table (i = 1, total = 90; i = 2, total = 160), the fixed output 80.0, the output 10 in step 4, and the shortcuts found without asking anyone, which is exactly the independent use of documentation the course expects.

Your turn

1

Name four main parts of an IDE.

2

What is syntax highlighting, and how does it help?

3

What is a breakpoint?

4

What is the difference between step over and step into?

5

Why is auto-indent especially useful in Python?

6

The debugger is paused at a breakpoint on x = x + 1 and shows x = 4. What will it show after you step over?

More practice: warm-up

1

What do the letters IDE stand for?

2

Name the IDE that comes with Python.

3

Where do error messages usually appear in an IDE?

4

What does the variables (watch) panel show?

5

Which built-in Python function pauses a program in the text debugger?

More practice: on your own

1

A program has a loop that runs 1000 times, and the bug only appears near the end. Why is setting a breakpoint better than stepping from the first line?

2

Explain why the debugger could not find a syntax error the way it found the bug in average.

3

In the buggy average program, what would the output be for average([10, 20, 30, 40])? Explain.

4

Your IDE underlines prnt("hi"). What has probably happened, and what does auto-completion do to prevent it?

5

A friend says, "I don't need a debugger; I'll just add print statements." Give one advantage of each approach.

Challenge

1

This function should return the largest number in a list, but biggest([3, 9, 4]) returns 4. Describe how you would use the debugger to find the bug, and fix it.

  1. def biggest(nums):
  2.     best = nums[0]
  3.     for n in nums:
  4.         if n > best:
  5.             best = n
  6.         best = n
  7.     return best
2

Explain how "step out" saves time when you accidentally stepped into a long function you trust.

3

Compare IDLE and a professional IDE such as VS Code. Give one reason a beginner might prefer each.

Check your understanding

Quiz

1.

Which part of an IDE lets you pause a program and inspect variables?

2.

A breakpoint is set on line 6. When the program runs in debug mode, it pauses...

3.

The current line is y = double(x). You want to see each line inside double. Which command?

4.

Which editor feature shows keywords, strings and comments in different colours?

5.

In the buggy average program, why was the answer wrong?

6.

Which is not a main component of an IDE?

For parents and teachers

Big idea: Expectation C3.1 asks students to demonstrate an understanding of an IDE and its main components (source code editor, compiler or interpreter, debugger). This lesson also starts C3.2, finding help independently, through the activity's final step.

How to help: Ask your teen to give you a "tour" of their IDE and to show you the debugger pausing on a line. Thonny (thonny.org) is free and works well at home. When your teen is stuck, ask "What does the debugger show the variable is?" before offering any answer.

Common difficulties:

  • Expecting a breakpoint to pause after its line.
  • Using step into on built-in functions and getting lost; use step out to come back.
  • Trying to debug a program with a syntax error; it never starts, so fix the syntax first.
  • Mixing up the editor (where code is written) and the shell (where output and errors appear).