## free style checker · runs in your browser

Check your Python code against PEP 8

Paste a snippet or open a .py file to see pycodestyle-style warnings for layout, whitespace, blank lines, imports and common comparisons. Nothing is uploaded. Then read why each rule exists: Four Spaces is an independent publication about Python style and readable code.

style check · pycodestyle subset

Runs entirely in your browser: your code is not uploaded, stored or logged.

What this checker covers

It is a JavaScript port of part of pycodestyle, the reference PEP 8 checker, and uses the same codes and messages. Before publication it was compared with pycodestyle 2.15 on more than 900 real Python files and gave the same results for the codes below in all but four of more than 27,000 warnings; three of the differences were inside f-string expressions, which it does not check.

  • E1, W191: indentation not a multiple of four, unexpected or over-indentation, tabs, tabs mixed with spaces (E101).
  • E2: whitespace inside brackets, before commas and colons, around operators (E225, E231), keyword arguments (E251, E252), inline and block comments.
  • E3: blank lines around functions, classes and methods (E301 to E306).
  • E4, E501: one import per line, imports at the top; line length.
  • E7: compound statements, == None (E711), == True (E712), not x in y, type comparisons, bare except:, assigned lambdas, ambiguous names.
  • W2, W3, W605: trailing whitespace, missing final newline, blank lines at the end, invalid escape sequences.

What it does not check

Continuation-line alignment (E12x), line breaks around operators (W503, W504), naming conventions, docstrings, unused imports and other errors, and type errors. Like pycodestyle, it skips the checks PEP 8 does not require by default, such as E226.

For whole projects, run the real tools: how to check Python style locally with pycodestyle, flake8 or ruff. Each code is explained in our pycodestyle error code reference.

PEP 8, section by section

All PEP 8 guides

The official style guide explained rule by rule, with the warnings each rule produces.

A long workshop hall filled with rows of nineteenth-century printing presses and their leversPEP 8, section by section

PEP 8, explained section by section

What the official Python style guide actually says, section by section, which parts tools can check, and where it tells you to use your judgment.

 Rows of students typing on heavy manual typewriters in a high-school classroom, with a blackboard behind themPEP 8, section by section

Indentation and line length

Four spaces, no tabs, 79 characters: where these numbers come from, how to wrap long lines cleanly and which warnings point to each problem.

 Compositors in shirtsleeves standing at tall wooden type cases in a newspaper composing room, early 1900sPEP 8, section by section

Whitespace and blank lines

Spaces around operators and commas, none inside brackets, two blank lines between functions: the rules, the warnings, and the one place the checker disagrees with PEP 8.

Linters & formatters

All tool guides

pycodestyle, flake8, pylint, black, ruff and pre-commit, described from their documentation.

A young woman in a 1940s office operating a card punch machine, a stack of punched cards beside herLinters & formatters

Check style locally

Install a checker in a virtual environment, run it on your project, configure it once and let it fix what it can: pycodestyle, flake8 and ruff step by step.

 A man and a woman working at the control console and tape units of an IBM 704 computer in a 1950s machine roomLinters & formatters

Ruff: linter and formatter

One tool for linting, import sorting and formatting: how ruff's rule codes work, how to choose them, and what its fixes will and will not change.

 An engraving of a two-handled printer's composition roller used for inking typeLinters & formatters

Black, the code formatter

88 characters, double quotes and the magic trailing comma: what Black changes, the few options it has, and how to make it agree with your linter.
A mover in a blue T-shirt tapes up a tall cardboard box in an apartment, with more boxes on the floor # practical guide

Relocating as a software developer: a checklist for your first months in a new city

Paperwork and the right to work, a home with a good connection and a sane commute, the first week's admin, and onboarding into a new codebase while you settle into a new city.

Read the checklist

Docstrings, comments & types

All documentation guides

Documentation that lives in the code: PEP 257, useful comments and type hints.

A dark grey museum wall label with a printed introduction text about devotional paintings and altarpiecesDocstrings, comments & types

Docstrings and PEP 257

One-line summaries in the imperative, a blank line, then the details: what PEP 257 asks of docstrings, the common formats and the tools that check them.

 Close-up of a medieval handwritten manuscript page in brown ink, with notes squeezed into the margin of the facing pageDocstrings, comments & types

Writing useful comments

Comments that contradict the code are worse than none: PEP 8's comment rules, what is worth explaining, and what to delete instead.

 A single red jigsaw puzzle piece lying on top of a heap of green pieces on a wooden tableDocstrings, comments & types

Type hints, explained

Annotations do nothing at runtime and a lot for readers and checkers: the syntax from PEP 484 to Python 3.12 generics, formatting rules and gradual adoption.

Readable code in practice

All practice guides

What the linter cannot see: readability, code review and bringing old code in line.

Rows of students reading at long desks in the Library of Congress reading room, around 1900, with marble columns behindReadable code in practice

Readable code, beyond PEP 8

Code can pass every linter and still be hard to follow. Names, flat control flow, small functions and idioms that say what they mean, with a before-and-after.

 Students in a late nineteenth-century printing shop standing at slanted type cases, setting type by handReadable code in practice

Python code review checklist

Automate the style, then review what tools cannot see: behaviour, tests, names, error handling and security, plus how to phrase comments people can act on.

 The United States Capitol seen across a wide lawn, with scaffolding on part of its facade during renovationReadable code in practice

Adopting a style guide in old code

One big reformat or a gradual rollout? How to bring an old codebase in line with PEP 8 while keeping git blame useful and open branches mergeable.

More from PEP 8

All PEP 8 guides

Naming, imports and the programming recommendations at the end of the guide.

Two green street name signs, SE Nye Av and SE 3rd Dr, mounted on a pole above the back of a stop sign under a grey skyPEP 8, section by section

Naming conventions

snake_case for functions, CapWords for classes, capitals for constants, and what one or two underscores really do, with the tools that check names.

 Aerial view of a large container port with green gantry cranes and long rows of stacked shipping containersPEP 8, section by section

Imports: order and grouping

One import per line, at the top, in three groups: the PEP 8 rules for imports, the exceptions, and how isort or ruff sort them for you.

 A cluttered bicycle workshop with a wheel on a truing stand, spare parts on the bench and tools hanging on a pegboardPEP 8, section by section

PEP 8 programming recommendations

Why `is None` beats `== None`, why bare `except:` is risky and why a lambda should not get a name: the habits at the end of PEP 8, with tested examples.