Basic

Not every note needs a fix

A review comes back with three or four notes, and it's tempting to change all of them at once. It isn't necessary. Some are worth your time; some can wait. This lesson is about telling them apart before you touch a single line.

What you will see

Without the check, bad input slips through and breaks code a few lines later.

About 2 min of reading

Quick check

Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.

Try It

A review comes back with notes, and not every one needs a fix. I show a set that makes membership fast no matter how big the data is, sort the notes by how much they matter, then explain why understanding the bug matters before editing.

Some notes pay off immediately when applied. I compare checking membership in a list against a set and print that both miss the item, but a set keeps the same speed as the data grows instead of scanning every time.

list_of_ids = ["a", "b", "c"] set_of_ids = {"a", "b", "c"} start_time = 0 print(f"in list: {('d' in list_of_ids)}") print(f"in set: {('d' in set_of_ids)}")

Before you run it, say out loud what it will print. Then open the answer.

What it prints

in list: False in set: False

Replace `x in list` with `x in set`, and build the set outside the loop so you do not rebuild it on every pass.

Not all notes sit at the same height on the ladder. I store three notes with priorities and print them sorted from the crash-inducing bug down to the style choice that can wait.

notes = {"bug": "crash on empty", "slow": "list scan in loop", "style": "rename var"} priority = {"bug": 1, "slow": 2, "style": 3} for name in sorted(notes, key=lambda k: priority[name]): print(f"{priority[name]} {name}: {notes[name]}")

Before you run it, say out loud what it will print. Then open the answer.

What it prints

1 bug: crash on empty 2 slow: list scan in loop 3 style: rename var

Fix bugs and risky ones first. A style tip about spacing can wait until the working part is finished.

Before you change anything, make sure you understand what is wrong. I pass an explanation of why a missing check is a bug and print it back to show that a fix you do not understand just moves the problem elsewhere.

def why(explanation): return explanation print(why("Without the check, bad input slips through and breaks code a few lines later."))

Before you run it, say out loud what it will print. Then open the answer.

What it prints

Without the check, bad input slips through and breaks code a few lines later.

Never apply a fix you cannot explain. Asking why turns a random edit into something you will remember the next time you write similar code.

Put it in order

Before you write anything, put these lines back in the right order. Click a line to move it up one step. This support step is easier than writing code from scratch, and it is here to make the last example stick.

Data Flow

Read the notes, sort them by how much they matter, fix the important ones, and learn something from each.

1 Read all the notes first

↓

2 Group them: bugs, speed, style

↓

3 Fix the bugs and the risky ones

↓

4 Ask "why" if a note is unclear

Line by line

Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.

list_of_ids = ["a", "b", "c"] sets nothing on screen

set_of_ids = {"a", "b", "c"} sets nothing on screen

start_time = 0 sets nothing on screen

print(f"in list: {('d' in list_of_ids)}") in list: False

print(f"in set: {('d' in set_of_ids)}") in set: False

Why this works

Fix the important ones first

Security problems and crashes go at the top. A style tip about spacing can wait until the working part is done. If a note doesn't make sense, ask the AI to explain it before you change anything.

Understand it before you edit

Never apply a fix you can't explain. Ask "why is this a problem?" and wait for the answer. Learning the reason once means you won't need the reminder twice, that's the difference between copying and actually understanding.

Examples

The fix that pays off immediately

AI: "You check membership with a list. Use a set instead."
You: "How do I actually change that?"
AI: "Replace `x in list` with `x in set`, and build the set outside the loop."

for tag in all_tags:
    if tag in list_of_ids:   # scans the whole list every time
        pass

A set finds a match in roughly the same time no matter how big the data is. Once you make the change, the speed difference is obvious the moment the list grows.

Sorting the notes into "now" and "later"

AI: "Three notes: a bug, a slow loop, and a naming idea."
You: "I'll fix the bug first."

Not all notes sit at the same height on the ladder. The bug can crash the app. The slow loop only matters once the data grows. The naming idea is just your preference. Handle them in that order:

Bugs that break things
Slow code that's actually in the way
Style choices you can come back to later

Asking "why" before editing

You: "Why is a missing check a bug?"
AI: "Without it, bad input slips through and causes problems a few lines later."

Before you change anything, make sure you understand what's wrong. A fix you don't understand just moves the problem somewhere else. Asking "why is this a problem?" turns a random edit into something you'll remember the next time you write similar code.

Words this lesson uses

Each one is defined here on this site. Open the entry for the full definition and the other words it points at.

← What actually happens when you ask an AI to review your code?

Previous Lesson

What actually happens when you ask an AI to review your code?

Next Lesson

Your first full review

Your first full review →