Pythonoid

CurriculumThe Dragon's Cleanup

Writing Clean Python Code, for Kids

A name never changes what code does — only whether a human reading it later can tell what it's for.

12 exercises4 lessonsAges 10+PRO
See what PRO unlocks →

What this topic covers

This topic opens with a demonstration rather than an assertion: the exact same calculation, once written with meaningless single-letter variables and once with real names, produces the identical output both times. Python genuinely does not care what anything is called — the entire value of a good name is for the human reading the code afterward, and stating that plainly, rather than treating good naming as an unexplained style preference, is the point.

Magic numbers — bare literals with no stated meaning nearby — get the same treatment: not a warning to take on faith, but a demonstrated bug. The same threshold, typed as a bare number in two different places, quietly drifts out of sync when only one occurrence gets updated. A named constant makes that specific failure structurally impossible, since both checks then read the same name rather than two literals that merely happen to currently match.

The topic closes on two levels of duplication, taught as genuinely different skills: spotting identical repeated lines, and the harder task of recognising two functions that look different — different names, a different hardcoded number — but share the exact same underlying shape. Extracting that shared shape into one parameterised function is where the topic ends, with a combined refactor level whose only real test is behaviour preservation: the code must do exactly what it did before, and do it more clearly.

Python from this topic

x = 100
y = 30
z = x - y
print(z)
# vs.
health = 100
damage = 30
remaining_health = health - damage
print(remaining_health)

Output

70
70

Python covered here

  • Why a variable's name never affects what a program computes
  • Magic numbers, and the real inconsistency bug they cause
  • Named constants as the fix — one value, one place it's defined
  • Spotting exact duplication vs. structural duplication
  • Extracting a repeated shape into a function with a parameter
  • Refactoring: changing how code looks without changing what it does

The mistake this topic is built to fix

Common mistakeA child treats naming, named constants, and avoiding duplication as arbitrary style preferences with no real consequence if ignored.

Each idea in this topic is demonstrated as a concrete, reproducible failure rather than argued as good taste: identical output regardless of naming, a real inconsistency bug from a duplicated magic number, and a structural-duplication pair that a naive text search would miss entirely. The goal is a learner who can point to a specific reason each practice matters, not one reciting a rule.

The lessons, in order

  1. Naming as a thinking toolA name never changes what code DOES — only whether a human can tell what it's FOR.3 exercises
  2. Magic numbers and named constantsA bare number with no stated meaning is a bug waiting to happen the moment it needs to change.3 exercises
  3. Spotting duplicationSome duplication is the same lines repeated. Some is harder to see — the same SHAPE, wearing different names.3 exercises
  4. The Dragon's Messy FunctionBad names, a magic number, all in one function — refactor it without changing what it does.3 exercises

Lessons unlock in order within a topic, so nothing arrives before the idea it depends on. This topic is part of PRO — $6.99 unlocks it along with everything else.

Try it now

The very first level needs no account at all — see whether it clicks before signing up for anything.

Play the first level free →