lesson 3.8.1 the problem with long code

Identifying the Issues with Repetitive Code

Ever tried to follow a recipe that was just one giant, rambling paragraph? It would be a nightmare! Good instructions are broken down into clear, numbered steps.

It's exactly the same with coding.

So far, our programs have been getting longer and longer. In this lesson, we're going to become "Code Detectives" and look at a program that's written in a really messy, repetitive way. Our job is to figure out why it's so bad and why professionals, like Software Developers and Games Engineers, would never write code like this. This is the first step to learning how to write cleaner, smarter, and more powerful programs.

Learning Outcomes

The Building Blocks (Factual Knowledge)

Describe that a "monolithic" program is one written as a single, long block of code.

Recall that code readability is improved by meaningful names and comments.

Identify that repeating code is inefficient and hard to maintain.

The Connections and Theories (Conceptual Knowledge)

Explain why procedural abstraction (hiding complexity in a function) is useful.

Explain that functions are a way to encapsulate and reuse patterns of instructions.

Analyse how decomposition (breaking a problem down) makes code easier to understand and debug.

The Skills and Methods (Procedural Outcomes)

Apply logical reasoning to trace the flow of a given program.

Analyse a given script to identify repeated sections of code.

Evaluate a program and identify its flaws in terms of readability, debugging, and modification.

Digital Skill Focus: Navigate a hierarchical folder structure to locate and open a specific Python file.

What is "Bad" Code?

So far, we've focused on writing code that works. But in the world of professional programming, just "working" isn't good enough. "Good" code must also be...

readable (by humans),

easy to debug (by humans), and

simple to maintain (which means update or change later, by humans).

"Bad" code is often...

monolithic (meaning it's just one single, long block of code)

repetitive (with the same lines of code copied and pasted over and over).

makes code review hard (which is a big part of a software developers job).

Task 1 Code Detectives: The Case of the Repetitive Village

Get organised

Download the bad-code-village.py Python file. It will very likely be saved in your downloads.

From the Start menu, open up the Thonny IDE (or equivalent if you haven't got Thonny installed)

Choose File > Open, locate the Python file and open it but DON'T run it yet...

PRI(MM)

Predict: Before you run it, read the code. What do you think this program will draw?

Run: Now, run the program. Was your prediction correct?

Investigate: Open up this WHITEBOARD and use it record your answers these three Code Detective questions:

Question 1: What does the program do?

Question 2: Can you spot which lines of code are repeated over and over?

Question 3: If your boss (the Project Manager) asked you to change the colour of all the roofs from "blue" to "green", what would be the problem with this code? What if you had to draw 100 houses?

Full screen ahead!

When you've answered the three questions, click the full-screen button on your whiteboard so your teacher can see your answers!

Outcome: I will have a text file with answers to the three investigation questions, and I will be able to explain to my teacher why this code is badly written. [/task]

The Problem with Change

Great detective work! You've all spotted the problem. The code is long, messy, and hard to change. If we made a mistake drawing the first house, we would have copied that mistake two more times! This is a huge problem for professional programmers.

Now, let's see just how bad this problem can get. You're going to get some new requests from your "client". This is the "Modify" step of PRIMM, where we try to change the code and see what happens.

Task 2 The Frustrating Client

Your client is back with new requests! You must modify the original Python script to meet their demands so the village looks like this..

Oooo, that looks better!

Get organised

Make sure you still have your original working bad-village-code.py file open.

If you need a fresh copy, download it from Task 1.

Challenge: The New Colour Scheme

Find all the lines of code that set the colour for the house base (the square). Change the colour from

red

yellow

Find all the lines of code that set the colour for the roof. Change the colour from

blue

green

Run your code. Do all three houses have the new colours?

Challenge: Add Some Windows!

Your client now wants a window on every house.

Copy the block of code below...

# --- Add a window ---
t.penup()
t.goto(t.xcor() + 20, t.ycor() + 20)
t.pendown()
t.fillcolor("cyan")
t.begin_fill()
for i in range(4):
    t.forward(20)
    t.left(90)
t.end_fill()
t.penup()
# --- Finished window ---

You must paste this entire block into your program in the correct place to add a window to the first house. (Hint: It should be drawn after the square base is finished, but before the turtle moves up to draw the roof).

Run your code to check it works.

Now, do the same for the second and third houses. This is tricky! You must find the exact right spot to paste the code.

Fancy a challenge? Can you add three more window to each house in the correct places to create this windowier village?

So many windows!

This process is getting very tricky now because you have 12 virtually identical sections of code, one for each window. How easy would you find it to locate one specific window in order to changes it's colour to, say, black?

Outcome: I will have a modified Python program that draws three yellow houses with green roofs and cyan windows. I will also understand why this was a very annoying and difficult way to work.

Today you have learnt why monolithic, repetitive code is a huge problem. It’s hard to read, hard to fix, and even harder to change without breaking something. In our next lesson, we will learn the solution: procedures!