Python Style Guide (PEP 8) – Complete Beginner Guide
Master PEP 8, the official Python style guide: naming conventions, code layout, indentation, docstrings, imports, line length limits, Ruff & Black tools, and good vs bad code examples.
When programmers start learning Python, one of the first things they fall in love with is how remarkably readable and expressive the language is. Unlike C, C++, or Java, Python has no curly braces {} to denote code blocks and no mandatory semicolons ; at the end of every line.
However, this visual simplicity comes with a shared responsibility: to keep Python code clean, uniform, and effortless to read for humans.
That is precisely where PEP 8 comes in. Whether you are submitting college lab assignments, creating open-source repositories on GitHub, or interviewing for a software engineering role, adhering to PEP 8 is what separates an amateur coder from a polished, hireable Python developer.
In this exhaustive beginner guide by Er. Sumit Kumar at MSK Institute, you will learn everything you need to know about PEP 8—from naming rules and whitespace mechanics to automated tools like Ruff, Black, and Flake8.
1. What is PEP 8?
The acronym PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, describing a new feature, process, or environment for Python.
PEP 8 is the eighth enhancement proposal ever written for Python, authored in 2001 by Guido van Rossum (the creator of Python), Barry Warsaw, and Nick Coghlan.
The primary purpose of PEP 8 is to provide the official coding style guide for the Python standard library. Over the last two decades, it has evolved into the universal, de-facto style standard adopted by every professional Python team, open-source project, and enterprise worldwide.
If you open the MSK Code Playground and run import this, the very first lines you will see are:
PEP 8 is the practical, day-to-day blueprint that translates those Zen philosophical axioms into concrete formatting rules.
2. Why PEP 8 is Important
Why should you spend time worrying about spaces, line lengths, and letter cases when your code already runs and produces the correct output?
Here is why writing PEP 8 compliant code is non-negotiable:
1. Human Readability & Lower Cognitive Load
Developers spend approximately 75% of their working hours reading, debugging, and reviewing existing code, and only 25% writing fresh code. When code adheres to uniform styling, your brain does not have to spend energy decoding erratic indents or weird capitalization—you can focus entirely on business logic.
2. Frictionless Team Collaboration
In professional development teams, multiple engineers commit code to the same repository daily. If one developer uses 2 spaces, another uses tabs, and a third creates 160-character single-line monstrosities, Git diffs become noisy nightmares and pull request reviews become frustrating debates over syntax aesthetics instead of software logic.
3. Fewer Indentation Bugs
Because Python relies on whitespace indentation to define scope and control flow (unlike languages with {} blocks), sloppy spacing can lead to catastrophic bugs. Adhering to strict 4-space indentation eliminates accidental indentation leaks. Learn more about structure in our Python Syntax and Code Structure Tutorial.
4. Technical Job Interviews & Code Audits
When technical mentors or hiring managers review your GitHub portfolio or coding test submissions, PEP 8 compliance is the first indicator of software maturity. A script with erratic naming (X1, calc_VAL, getData) instantly signals an inexperienced candidate, while clean PEP 8 code signals industry readiness.
3. Python Naming Conventions: The Complete Cheat Sheet
Python uses different casing conventions depending on whether an identifier represents a variable, a function, a class, or a module. Memorize this reference table:
| Identifier Type | PEP 8 Convention | Valid Example | Avoid |
|---|---|---|---|
| Variables | snake_case | student_name, total_score | studentName, TotalScore |
| Functions | snake_case (with verbs) | calculate_tax(), get_user_by_id() | CalculateTax(), calcTax() |
| Classes | PascalCase / CapWords | StudentProfile, PaymentGateway | student_profile, studentProfile |
| Constants | SCREAMING_SNAKE_CASE | MAX_CONNECTIONS, DEFAULT_TIMEOUT | maxConnections, max_connections |
| Modules (.py) | short_snake_case | math_utils.py, student_service.py | MathUtils.py, student-service.py |
| Packages | short_lower (no underscores) | mskinstitute, analytics | msk_institute, Analytics |
| Methods | snake_case | def process_payment(self): | def ProcessPayment(self): |
| Protected Member | _single_leading_underscore | _internal_cache, _sync_state() | — |
| Private Member | __double_leading_underscore | __auth_token (name mangling) | — |
| Keyword Clash | single_trailing_underscore_ | class_, id_, type_ | klass, my_class |
4. Functions, Classes, and Constants Naming in Detail
Let's dive into the specifics of naming each core Python building block:
Functions and Methods
Functions perform actions; therefore, their names should almost always begin with an active verb followed by a descriptive noun in snake_case:
Bad function names
Good function names (Action + Subject)
is_, has_, can_, or should_ (e.g., is_eligible, has_permission, can_submit). Read our full Python Functions Tutorial for deeper examples.Classes and Exceptions
Class names should use PascalCase (also called CapWords), where every word starts with a capital letter with no underscores:
Constants
Python does not possess a strict compiler-level const keyword like C++ or JavaScript. Instead, the Python community signals that a variable must never be mutated by typing it in SCREAMING_SNAKE_CASE at the module level.
Check out our dedicated tutorial on Python Constants Convention and Python Variables and Rules.
5. Indentation and Spacing: The Golden Rules
Rule 1: Always 4 Spaces per Indentation Level
PEP 8 is unequivocal: use 4 spaces per indentation level. Never use 2 spaces, never use 8 spaces, and never use tabs.
Python 3 strictly disallows mixing tabs and spaces for indentation in the same file. If you mix them, Python will halt execution with a TabError:
Ctrl + ,), search for Editor: Insert Spaces, and check it. Then set Editor: Tab Size to 4. When you press the Tab key, VS Code will automatically insert 4 spaces for you.Rule 2: Hanging Indents and Line Continuation
When a statement, function header, or list is too long to fit on one line, use hanging indents with Python’s implied line continuation inside parentheses (), brackets [], or braces {}.
Rule 3: Blank Lines
Blank lines give breathing room to code so readers can discern logical sections:
- Surround top-level functions and class definitions with two blank lines.
- Surround method definitions inside a class with one blank line.
- Use blank lines sparingly inside functions to separate distinct computational steps (like input validation, processing, and output formatting).
Rule 4: Whitespace in Expressions and Statements
Pay close attention to where spaces should and should not be placed:
1. Immediately inside parentheses, brackets, or braces:
2. Immediately before a comma, semicolon, or colon:
3. Around assignment (=) and comparison (==, !=, <, >, <=, >=) operators:
4. Default parameter values in function definitions (NO spaces):
6. Imports and Line Length Guidelines
Maximum Line Length: 79 Characters
PEP 8 limits all lines to a maximum of 79 characters. For flowing blocks of text such as docstrings or block comments, the limit is 72 characters.
Why 79 characters?
In modern software development, developers frequently keep two to three editor tabs open side-by-side on widescreen monitors, or compare git diffs in split-screen pull request reviews. Limiting lines to 79 characters prevents awkward horizontal scrolling and keeps diffs cleanly visible on any screen or terminal.
How to Organize Imports
Imports must always be placed at the very top of your file, immediately after any module docstrings and comments, and before module globals or code.
PEP 8 mandates grouping imports into three distinct sections, separated by a single blank line:
- 1Standard Library Imports (modules bundled with Python:
os,sys,math,datetime,pathlib) - 2Related Third-Party Imports (installed packages:
requests,numpy,pandas,fastapi) - 3Local Application / Library Imports (your custom project modules)
Import Rules to Remember:
- One import per line: Write
import osandimport syson separate lines. Do not writeimport os, sys. - Allowed grouping:
from subprocess import Popen, PIPEis completely valid. - Never use wildcard imports: Avoid
from math import *. Wildcard imports obscure which names are present in the namespace, confuse linters, and cause silent variable shadowing bugs.
7. Comments and Docstrings (PEP 257)
Comments that contradict the code are worse than no comments at all. When code changes, always keep comments updated!
Inline Comments
An inline comment is a comment on the same line as a statement. PEP 8 specifies:
- Separate the comment from the statement by at least two spaces.
- Start with
#(a hash symbol followed by a single space). - Explain WHY, not WHAT: Never state the obvious.
For more guidance, check our Python Comments and Best Practices Guide.
Docstrings (PEP 257)
Docstrings are string literals that appear as the first statement in a module, function, class, or method. Unlike regular comments, docstrings are retained at runtime and can be inspected via help(function_name) or function_name.__doc__.
- Always use triple double-quotes:
"""...""". - For one-line docstrings, keep the closing quotes on the same line.
- For multi-line docstrings, document arguments (
Args:), return values (Returns:), and potential errors (Raises:).
8. Good vs Bad Code Examples: Side-by-Side Comparison
Let's inspect how a typical unformatted script transforms into clean, professional PEP 8 code.
The Bad Code (Violates PEP 8)
What makes this code bad?
- Multiple imports on a single line (
import math,os,sys). - Dangerous wildcard import (
from datetime import *). - Inconsistent naming:
MaxScoreis PascalCase instead of uppercase constantMAX_SCORE. - Non-standard function name:
Calc_grademixes title case and underscores. - Spaces around default argument:
bonus = 5. - Missing whitespace around binary operator:
Score+bonus. - Class name
student_datauses snake_case instead of PascalCaseStudentData. - Non-standard instance identifier
Selfinstead of lowercaseself. - Semicolon and statement on same line as
else:. == Nonecomparison instead of identity checkis None.
The Refactored Code (100% PEP 8 Compliant)
Notice how much easier the refactored version is to read, understand, and debug!
9. Modern PEP 8 Tooling: Ruff, Flake8, and Black
Manually memorizing every single spacing and comma rule can feel overwhelming. Fortunately, the Python ecosystem provides world-class automated linters and code formatters.
1. Flake8: The Classic Linter
Flake8 is the longstanding community standard linter. It bundles three tools:
PyFlakes(checks for logical errors like undefined variables or unused imports)pycodestyle(checks for PEP 8 formatting violations)mccabe(checks code complexity)
Flake8 outputs error codes corresponding to PEP 8 rules (e.g., E302: expected 2 blank lines, E501: line too long (88 > 79 characters), W291: trailing whitespace).
2. Black: "The Uncompromising Code Formatter"
While Flake8 warns you about errors, Black actually fixes them automatically. It parses your Python files into an Abstract Syntax Tree (AST) and reformats your code deterministically according to strict PEP 8 principles.
black --line-length 79 ..3. Ruff: The Ultra-Fast Modern Python Standard
In modern Python development (2024–2026), Ruff has revolutionized code tooling. Built from scratch in Rust by Astral, Ruff is 10 to 100 times faster than Flake8, Black, and isort combined. It replaces dozens of legacy tools with a single unified binary.
Recommended VS Code Setup
To make PEP 8 compliance effortless:
- 1Open the VS Code Extensions tab (
Ctrl + Shift + X). - 2Search for Ruff (by Astral Software) and install it.
- 3Add this to your
.vscode/settings.json:
With this setup, every time you press Ctrl + S, your file will automatically be formatted to PEP 8 standards!
10. PEP 8 vs Coding Best Practices: What's the Difference?
A common misconception among beginner programmers is equating PEP 8 with overall software engineering quality. While closely related, they address two distinct layers:
| Dimension | PEP 8 (Style Guide) | Coding Best Practices (Engineering) |
|---|---|---|
| Focus | How code looks (aesthetics, formatting) | How code functions & scales (architecture) |
| Examples | 4 spaces, snake_case, blank lines, max 79 chars | DRY, SOLID principles, design patterns, testing |
| Enforced By | Formatters & Linters (Ruff, Black, Flake8) | Unit tests, architecture design, peer reviews |
| Bugs Prevented | Indentation errors, variable name collisions | Memory leaks, race conditions, unhandled exceptions |
| Importance | High (Visual clarity & team consistency) | Critical (Correctness, security, scalability) |
When to Ignore PEP 8: The Golden Caveat
In the opening section of PEP 8, Guido van Rossum explicitly included a famous quote by Ralph Waldo Emerson:
PEP 8 is a guide, not a religious dogma. You should deliberately break PEP 8 in situations where:
- 1Applying the rule would make the code LESS readable, even for someone used to reading PEP 8 code.
- 2Maintaining consistency with legacy surrounding code that already uses a different style.
- 3Preserving backward compatibility with an established public API or external library that uses camelCase.
11. Frequently Asked Questions (FAQ)
Q1: Does following PEP 8 make my Python programs run faster?
No. Python’s bytecode compiler strips out whitespace, indentation, comments, and docstrings when creating .pyc files. A poorly formatted script and a PEP 8 compliant script will execute at the exact same speed. PEP 8 is designed for human execution speed—allowing developers to read, diagnose, and maintain code faster.
Q2: Why does PEP 8 mandate 79 characters when everyone has widescreen 4K displays?
While modern displays can fit 300 characters across a screen, human eyes struggle to track line breaks across very wide blocks of text (the same reason books and newspapers use narrow columns). Furthermore, engineers often view two files side-by-side in split screens while writing unit tests, or review side-by-side pull request diffs on GitHub. 79–88 characters fits comfortably in any split view.
Q3: Why should I write if val is None: instead of if val == None:?
In Python, None is a unique singleton object in memory. The == operator calls the object’s __eq__() magic method, which can be overridden by a class to return unexpected results. The is operator tests identity (whether both operands reference the exact same memory address using id()), which is faster, safer, and idiomatic Python.
Q4: Should I use snake_case for everything in Python?
No. Use snake_case for variables, function names, and method names. Use PascalCase for classes and custom exceptions, and use SCREAMING_SNAKE_CASE for global module-level constants.
Q5: Can I use PEP 8 in Jupyter Notebooks and Google Colab?
Yes! In Jupyter Notebooks, you can format cells using Ruff or Black with the nbqa library (pip install nbqa), or install the JupyterLab code formatter extension. Clean formatting in data science notebooks is essential for reproducible research.
Q6: Does PEP 8 mandate static type hints?
PEP 8 does not strictly require type hints (type annotations were later introduced in PEP 484). However, modern PEP 8 guidelines include spacing rules for type hints: use a space after the colon, but not before (name: str = "Sumit").
12. Next Steps & Recommended Python Resources
Mastering PEP 8 is one of the most rewarding milestones in your programming journey. Writing clean code builds discipline, improves problem-solving clarity, and sets you apart in every coding viva and technical interview.
Continue expanding your Python expertise with our structured resources:
- Interactive Practice: Run and test Python snippets in our browser-based MSK Code Playground.
- Core Curriculum: Follow our structured Python for Beginners Tutorial Series.
- Foundations: Learn Python Syntax and Code Structure and Python Variables and Rules.
- Interview Preparation: Review the Top 50 Python Interview & College Viva Questions (2026 Edition).
- Language Comparison: Read Python vs JavaScript: Which Programming Language Should Beginners Pick First?.
- Comprehensive Training: Enroll in our signature offline & online certification course: Python for Beginners Course or Python Mastery (3 Months).
Master These Skills in Our Offline Labs
Python for Beginners
Master Python programming from scratch in 1 month. Comprehensive hands-on curriculum covering variables, data types, numbers, strings, operators, data structures (lists, tuples, sets, dicts), control flow, loops, functions, file handling, and 4 real-world projects.
Python Mastery (Beginner to Advanced) - 3 Months
Master Python programming from zero fundamentals to enterprise software engineering in 3 months. This comprehensive 3-in-1 Grand Mastery Combo bundles Python for Beginners, Python for Intermediate, and Python for Advanced — spanning 45 chapters, 218 structured topics, 1,099 interactive quiz questions, and 14 production portfolio projects across OOP, multithreading, asyncio, networking, and databases.