# PEP 8

> Руководство по стилю кода на Python — отступы, длина строк, импорты, именование и пробелы.

Источник: https://llmdocs.ru/wiki/pep-8/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Название**: Style Guide for Python Code
- **Авторы**: Гвидо ван Россум, Барри Уорсо, Алисса Коглан
- **Создан**: 5 июля 2001
- **Тип PEP**: Process
- **Статус**: Active
- **Средства проверки**: pycodestyle, flake8, Ruff
- **Форматировщики**: Black, Ruff format, autopep8
- **Текст**: [peps.python.org/pep-0008](https://peps.python.org/pep-0008/)
**PEP 8** — официальное руководство по стилю кода на [Python](https://llmdocs.ru/wiki/python.md). Документ описывает, как оформлять отступы, переносить длинные строки, располагать импорты, ставить пробелы и называть переменные, функции и классы. PEP 8 не является требованием интерпретатора — код с нарушениями работает, — но фактически стал общим стандартом сообщества: ему следуют стандартная библиотека, большинство открытых проектов и автоматические инструменты.

## История

PEP 8 создан в июле 2001 года на основе эссе Гвидо ван Россума о стиле и руководства Барри Уорсо; позже соавтором стала Алисса Коглан.[1] Документ остаётся «живым»: его уточняют по мере развития языка, например после появления аннотаций типов и f-строк. Соглашения о строках документации вынесены в отдельный PEP 257.[2]

## Главная идея

Ключевая мысль сформулирована в разделе с ироничным названием «Глупая последовательность — пугало ограниченных умов»: код читают гораздо чаще, чем пишут, поэтому важна прежде всего читаемость.[1] Согласованность внутри проекта важнее согласованности с PEP 8, а согласованность внутри модуля или функции — важнее всего. Руководство прямо разрешает отступать от правил, если следование им ухудшает читаемость или ломает совместимость со старым кодом.

## Основные правила

**Отступы и строки**

- 4 пробела на уровень отступа, без табуляции.
- Максимальная длина строки — 79 символов, для комментариев и строк документации — 72. Команды могут договориться о большем лимите (до 99).
- Длинные выражения переносятся внутри скобок, а не обратной косой чертой; бинарный оператор лучше ставить в начале новой строки.
- Две пустые строки вокруг функций и классов верхнего уровня, одна — между методами.

**Импорты**

- Каждый импорт на отдельной строке, в начале файла.
- Порядок групп: стандартная библиотека, сторонние пакеты, модули проекта; между группами — пустая строка.
- Избегать `from module import *`.

**Пробелы**

```python
# правильно
spam(ham[1], {eggs: 2})
x = 1
def complex(real, imag=0.0): ...
result = func(a, key=value)

# неправильно
spam( ham[ 1 ], { eggs: 2 } )
x=1
def complex(real, imag = 0.0): ...
```

**Сравнения**

- С `None` сравнивают через `is` / `is not`, а не `==`.
- Пустые последовательности проверяют как ложные: `if not items:` вместо `if len(items) == 0:`.
- Типы проверяют через `isinstance()`, а не сравнением `type()`.

## Именование

| Что | Стиль | Пример |
|---|---|---|
| модули, пакеты | короткие, строчные | `mymodule` |
| функции, переменные, методы | `snake_case` | `load_config` |
| классы, исключения | `CapWords` | `HttpClient`, `ParseError` |
| константы | `UPPER_CASE` | `MAX_RETRIES` |
| «внутренние» имена | ведущее подчёркивание | `_cache` |
| избежание конфликта с ключевым словом | завершающее подчёркивание | `class_` |
| первый аргумент метода | `self`, у методов класса `cls` | |

Имена из двойного подчёркивания по краям (`__init__`) зарезервированы для специальных методов языка; придумывать собственные не следует.

## Инструменты

Следить за стилем вручную непрактично, поэтому используют автоматические средства:

| Инструмент | Что делает |
|---|---|
| pycodestyle | проверка соответствия PEP 8 (до 2016 года назывался `pep8`)[3] |
| flake8 | pycodestyle + поиск ошибок (pyflakes) + плагины |
| Black | форматировщик без настроек, строки до 88 символов[4] |
| [Ruff](https://llmdocs.ru/wiki/ruff.md) | быстрый линтер и форматировщик на Rust, включает правила pycodestyle (коды `E`, `W`)[5] |
| autopep8 | автоматическое исправление нарушений |

```bash
ruff check .            # найти нарушения
ruff check --fix .      # исправить то, что можно
ruff format .           # отформатировать код
```

Форматировщики снимают споры о стиле в код-ревью: оформление определяет инструмент, а люди обсуждают логику. Обычно их подключают к редактору, к Git-хукам (см. [Git-хуки](https://llmdocs.ru/wiki/git-hooks.md)) и к [конвейеру CI](https://llmdocs.ru/wiki/ci-cd.md).

## Сравнение с другими языками

Похожие соглашения есть у большинства языков, но степень формализации разная: в [Go](https://llmdocs.ru/wiki/go.md) стиль навязывает утилита `gofmt` без вариантов, в Rust — `rustfmt`, в JavaScript принято выбирать конфигурацию ESLint и Prettier. PEP 8 ближе к руководству, чем к закону, а жёсткость добавляют уже инструменты вроде Black.

## См. также

- [PEP](https://llmdocs.ru/wiki/pep.md)
- [Ruff](https://llmdocs.ru/wiki/ruff.md)
- [Python](https://llmdocs.ru/wiki/python.md)
- [mypy и pyright](https://llmdocs.ru/wiki/mypy-pyright.md)

## Источники

1. [PEP 8 — Style Guide for Python Code](https://peps.python.org/pep-0008/)
2. [PEP 257 — Docstring Conventions](https://peps.python.org/pep-0257/)
3. [pycodestyle documentation](https://pycodestyle.pycqa.org/)
4. [Black — The uncompromising code formatter](https://black.readthedocs.io/)
5. [Ruff — Rules](https://docs.astral.sh/ruff/rules/)