What Is PEP 8? The Python Style Guide Explained

What Is PEP 8?

PEP 8 is the official style guide for Python: a list of habits for how your code should look. Where to put spaces, how to name things, how long a line may be. It doesn't change what your program does. It changes how easy it is to read.

PEP stands for "Python Enhancement Proposal", a document that suggests something for Python. PEP 8 was written in 2001 by Guido van Rossum, the creator of Python, together with two other Python developers. Almost every Python programmer in the world follows it.

Think of it like handwriting rules at school: write on the lines, leave a space between words, start a sentence with a capital letter. Your teacher can still read messy handwriting, but neat handwriting is read faster, and with fewer mistakes.

Same program, two looks

123price=250;qty=3
total=price*qty
print("Total:",total)

1234price = 250
qty = 3
total = price * qty
print("Total:", total)

Both print the same thing. Python doesn't care which one you write. People do: the second one reads like a sentence.

What PEP 8 covers

Good news: you already follow some of these. You met snake_case in chapter 4, the 4-space indentation in chapter 8, and good comments in chapter 6. This chapter puts them all in one place, and adds the rest.

PEP 8 is Python's style guide: it changes how your code looks, not what it does.

Why Code Style Matters

Readability means how easy your code is for a person to read. PEP 8 is built on one idea from Guido van Rossum: "Code is read much more often than it is written."

You write a line once. Then you read it again and again: when you fix a bug, when you add a feature, when a teammate learns from it. So the reader matters more than the writer.

Think of it like recipe cards in a shared kitchen. If every cook writes cards the same way, ingredients first and steps after, anyone can pick up any card and start cooking.

Who reads your code?

• You, next month. You will forget why you wrote it that way.
• Your teammates. In a team, everyone writes in the same style, so the code looks like one person wrote it.
• Whoever checks your work: a teacher, a reviewer, or an interviewer.

Can you tell what this does?

1234x=1200
y=0.18
z=x+x*y
print(z)

It works, but what is x? What is y? You have to guess. Now the same program, written for the reader:

1234price = 1200
tax_rate = 0.18
price_with_tax = price + price * tax_rate
print(price_with_tax)

Now the code explains itself: a price, plus 18% tax. If the tax rate changes, you know exactly which line to edit.

Clean code hides fewer bugs

When code is tidy, a mistake stands out, like a crooked picture on a straight wall. In messy code, every line looks a little wrong, so the real bug blends in.

Common beginner doubt: "My program works. Why should I care about style?" Because working is only the first job of code. The second job is to be easy to read and change. Messy code that works today is hard to fix tomorrow.

You write code once but read it many times, so write it for the reader.

Style Rules vs Python Rules

Some rules are enforced by Python: break one, and your program stops with an error. Most PEP 8 rules are style rules: Python runs your code anyway, but people find it harder to read.

Think of it like a football match. A foul makes the referee stop the game. Passing badly is allowed, and the game goes on, but your team plays worse.

Two spaces work, but aren't the style

123if 5 > 3:
  print("Two spaces work")
  print("but PEP 8 says 4")

Python only needs the lines of a block to line up. It doesn't count how many spaces you use.

Mixing is the real danger

123if 5 > 3:
    print("Four spaces")
  print("Two spaces")

Don't be scared of this error! It's saying: "this line is moved left, but not to a place where any block starts". Unindent means moving a line back to the left. When you use 4 spaces every time, you never mix, and this error never happens.

So who checks the style?

You do. Python won't warn you about a missing space or a bad name. In this chapter's practice questions, the tests check your output only, so the style is your own job: read your code once more before you submit it.

Python enforces only a few rules. PEP 8 style is your job, so check it yourself.

Be Consistent: Pick One Way

The most important style rule is consistency: once you pick a way to write something, write it that way everywhere. PEP 8 itself says that consistency inside one project matters more than any single rule.

Think of it like the signs in a train station. It matters less which colour the exit signs are. It matters a lot that every exit sign has the same colour.

Quotes are a good example

Python accepts single and double quotes, and PEP 8 doesn't choose one for you:

123first_name = "Sunny"
last_name = 'Rocky'
print(first_name, last_name)

It runs, but a reader wonders: "Is there a reason these are different?" There isn't. Pick one kind and stick to it:

123first_name = "Sunny"
last_name = "Rocky"
print(first_name, last_name)

The one exception: when the text itself has a quote inside, use the other kind, so you don't need a backslash (chapter 2):

12print("It's Lucky's turn")
print('She said "hi"')

The rules

• Pick one style for quotes, names and spacing, and use it in the whole program.
• In a team, follow the team's style, even if you'd choose differently.
• When you change someone else's code, match the style that's already there.
• PEP 8 also says: if a rule makes one piece of code harder to read, it's fine to break it there. Readability is the goal, the rules are the tools.

Common beginner doubt: "Single or double quotes: which one is right?" Both are right. This course uses double quotes, so you'll see them everywhere here. What's wrong is switching between them for no reason.

Pick one way of writing each thing and use it everywhere.

Practice: PEP 8

Solve these to lock in what you learned in this topic. Each one runs in your browser.

1. 140.Python Program to Rewrite Squashed Code in PEP 8 StyleEasySolve
2. 141.Fix a Messy Python Program That Won't RunMediumSolve