Flowcharts

One-sentence summary

A flowchart draws the steps and decisions of an algorithm with standard shapes and arrows, turning the solution into a map you can see with your eyes.

Why does it matter?

Pseudocode describes an algorithm line by line. But as the number of decisions and repetitions grows, it gets harder to answer the question, “which path are we on right now?” This is where a flowchart helps: we draw the steps as a top-to-bottom map and, by following the arrows, we can see every path the program might take.

This skill is useful not only when writing code but also when explaining a problem to someone else. Instead of telling a classmate “in this case do this, in that case do that,” you can show a single chart. Before turning a new idea into code, I usually sketch a rough flowchart on paper first; it is easier to catch mistakes in the chart than in the code.

Flowchart symbols

The power of a flowchart comes from everyone using the same shapes with the same meaning. There are five basic symbols.

• Oval (start/end): Where the chart begins and ends. Every chart opens with a “Start” and closes with one or more “End” shapes.
• Rectangle (process): A task to carry out. For example, “fill the water bottle” or “add 1 to the number.”
• Diamond (decision): A question with a yes/no answer. Two arrows always leave a diamond.
• Parallelogram (input/output): Receiving information from outside or displaying information on the screen. For example, “get a number” or “display ‘Even number’.”
• Arrow (flow): Shows the direction from one step to the next. Following the arrows is the same as reading the program step by step.

Quick reminder: A shape tells you what is being done; an arrow tells you which step comes next.

Its relationship with pseudocode

A flowchart and pseudocode are two different views of the same algorithm. An “If … Otherwise” line in pseudocode corresponds to a diamond in the flowchart, while an ordinary command line corresponds to a rectangle. One is text, the other is a picture; the logic is the same.

Drawing a decision branch

A decision splits a flowchart in two. We label the two arrows leaving the diamond “Yes” and “No”; each arrow goes to a separate path, and both of those paths must eventually connect to an “End.”

Everyday example: “Is it raining?”

Goal: Decide whether to take an umbrella before going outside.

        [Start]
           |
   <Is it raining?>
      /            \
    Yes            No
     |               |
[Take umbrella] [No umbrella]
      \             /
        \          /
          [End]

In this chart, two arrows leave the decision box. Each path does a different action, but both meet at the same “End.” This way, whatever the weather is, we know where the program will finish.

Drawing a loop

Repetition (a loop) is shown in a flowchart with an arrow that goes backward. A decision box controls when the loop ends: as long as the condition holds, the arrow sends us back to the actions; once the condition breaks, the arrow carries us forward to “End.”

Everyday example: Counting from 1 to 5

   [Start]
      |
  [count = 1]
      |
  <count <= 5?> <-------+
    /       \           |
   No       Yes         |
   |          |         |
 [End]  [display count] |
              |         |
        [count = count+1]
              |         |
              +---------+

The backward arrow here is the heart of the loop. On each turn, count increases by one; once count passes 5, the decision box takes the “No” path and the loop ends. If we forget that increment step, count stays 1 forever and the loop never ends — this is called an infinite loop.

From pseudocode to flowchart: “Is the number even?”

Let us see the same algorithm in three forms: pseudocode, real Python, and a flowchart. The logic of all three is exactly the same.

Pseudocode:

Start
Get a number
If the remainder after dividing the number by 2 is 0
  display "Even number"
Otherwise
  display "Odd number"
End

Python:

number = int(input("Enter a number: "))

if number % 2 == 0:
    print("Even number")
else:
    print("Odd number")

Flowchart:

        [Start]
           |
     /get a number/
           |
   <number % 2 == 0?>
      /          \
    Yes          No
     |            |
/display "Even"/ /display "Odd"/
      \          /
         [End]

The parallelograms (/…/) here show input and output: getting the number is an input, displaying the result is an output. The decision box is the picture of the if/else line.

Mini practice

Take the pseudocode below and turn it into your own flowchart in text/ASCII form.

Start
Check the door
If the door is locked
  turn the key
Open the door
Go inside
End

While drawing your chart, watch for these:

1. Did you begin with a “Start” oval?
2. Did you show the locked condition with a diamond?
3. Do two arrows leave the decision box (if locked, turn the key; otherwise open directly)?
4. Do both paths meet again at the “Open the door” step and reach “End”?

Extra: Draw your chart on paper and hand it to a friend, then ask them to say the steps by following only the arrows, without your explanation. Wherever they get stuck is where the chart is unclear.

Common mistakes

Not connecting every path to the end

A decision box opens two paths. Sometimes we draw the “Yes” path and leave the “No” path hanging. If that empty arrow goes nowhere, it stays unclear what the program should do in that case. The rule: every arrow must lead somewhere, and every path must eventually connect to an “End.”

Giving a decision box only one exit

A diamond is a question, and a question always has two possible answers. If you draw only one arrow out of a decision box, then there is really no decision there; it should have been a plain rectangle (a process). Two arrows always — Yes and No — must leave a decision box.

Not labelling the arrows

If two arrows leave a box but it is not clear which is “Yes” and which is “No,” the chart cannot be read. Always label the arrows that leave a decision box.

Mixing up the shapes

Drawing a process as a diamond or a decision as a rectangle misleads the reader. Shape is a language: use a diamond when you want to ask a question, and a rectangle when you want an action done.

Lesson summary

• A flowchart draws the steps and decisions of an algorithm with shapes and arrows.
• There are five basic symbols: oval (start/end), rectangle (process), diamond (decision), parallelogram (input/output), and arrow (flow).
• Two arrows always leave a decision box, and every path eventually connects to an “End.”
• A loop is shown with an arrow that goes backward and a decision box that stops it.
• A flowchart and pseudocode are two views of the same algorithm; the logic is the same in both.

Check questions

1. Which symbol shows the start and end of a flowchart?
2. How many arrows should leave a diamond, and why?
3. Which symbol is used to display a message on the screen?
4. What element shows a loop in a flowchart?
5. Why is “not connecting every path to the end” a mistake?

Answers

1. It is shown with the oval symbol. Every chart opens with a “Start” oval and closes with one or more “End” ovals.
2. Two arrows should leave it: one “Yes” and one “No.” Because a decision is a question with a yes/no answer, and both answers must have a path.
3. It is shown with the parallelogram (input/output) symbol; displaying information on the screen is an output.
4. It is shown with a backward-going arrow; this arrow returns the flow to earlier steps until a decision box breaks the condition.
5. Because if a path connects to nothing, it stays unclear what the program should do when it reaches that situation; in a good chart, every path ends at a defined finish.

Source and verification note

For “Flowcharts”, verification focuses on whether the relationship between Flowchart symbols and Drawing a decision branch remains consistent across examples. The algorithms in this lesson are checked by tracing sample inputs by hand and comparing them with expected outputs. Pseudocode is used to make the reasoning sequence visible without tying it to one programming language.

Next lesson

Debugging: Methods for finding and fixing a mistake step by step when an algorithm or program does not work the way we expected.