Читай PEP 8 — пиши код как ван Россум

В борьбе за красивый и понятный код Python-сообществу нужны ориентиры: что такое хорошо и что такое плохо. Создатель языка Гвидо ван Россум (Guido van Rossum) и его соратник Барри Уорсо (Barry Warsaw) описали хороший стиль Py-кода в документе PEP 8.

Каждый уважающий себя питонист обязан знать этот стандарт. Читайте оригинал или перевод , главное — вдумчиво!

Краткий обзор PEP 8 ниже поможет вам ориентироваться в руководстве. Но это ни в коем случае не альтернатива оригиналу, который во время занятий Python хорошо бы держать под рукой.

Зачем нужен PEP 8

Единый стиль оформления делает код понятным для самого программиста и его коллег с разным уровнем подготовки.

В идеале наиболее сложный фрагмент кода должен быть понятен с первого прочтения. Это упрощает командную разработку и обучение новичков, позволяет вам быстро возвращаться к собственным давним проектам.

Гвидо ван Россум

PEP 8 затрагивает структуру и внешний вид кода:

выбор кодировки исходного кода;

группировку инструкций по импорту модулей;

максимальную длину строки кода — рекомендуется до 79 знаков, а для строк документации (docstring) — 72 знака;

использование отступов — табуляции и пробелов;

использование пустых строк для разбивки кода на блоки и выделения функций верхнего уровня;

именование переменных, констант, классов и экземпляров, функций, аргументов, модулей, пакетов;

выбор уровня доступности классов и методов (public, private, API-подклассы), а также порядка их наследования.

Пишете ли вы код в PyCharm, Notepad++ или другом редакторе, сохранять .py-файлы лучше в кодировке UTF-8. Для Python 3 она рекомендована официально, для Python 2 формально требуется кодировка ASCII, но она не поддерживает кириллицу, поэтому для приложений на русском разумно использовать ту же UTF-8. Если по какой-то причине вам очень нужна «альтернативная» кодировка исходника, обязательно укажите её в комментарии в первой строке файла:

Без этого комментария интерпретатор выдаст ошибку.

PEP 8: Питону важны отступы

Самое известное требование PEP 8 по оформлению Python-кода — отступы . С их помощью задают структуру условий, циклов, функций. Традиционно на один уровень отступа ставят четыре пробела . Например:

Теоретически вы можете использовать иное число пробелов: 2, 8 и т.д. Главное, чтобы оно совпадало по всему коду — иначе интерпретатор будет ругаться. Но 4 — «золотой стандарт» сообщества: быстро ставить, привычно читать.

В чужом коде вам может встретиться другой вид отступа — табуляция. Его PEP 8 категорически не рекомендует, но с одной оговоркой. Если вы дорабатываете готовый проект, где отступы сделаны табуляцией, придерживайтесь принятого до вас стандарта. Если в коде разнобой, замените всё на пробелы.

Сразу после открывающей скобки и перед закрывающей: ( x ) — так не надо.

Перед скобками при вызове аргумента. Неправильно: arg (1). Правильно: arg(1).

Перед скобками индекса и среза: dict['step'] = map[i].

Между именем параметра/аргумента, знаком «=» и значением: min(a=10, b=input).

И, пожалуйста, не выравнивайте код лишними пробелами. По сторонам от «=» ставьте не больше одного пробела. Не пытайтесь с помощью отступов придать блоку вид таблицы или оглавления. Это замедляет чтение и понимание написанного.

Лучше ставьте по одному пробелу по сторонам от знаков арифметических действий:

Не рекомендуется записывать несколько команд в одну строку через точку с запятой. Вместо "act1(); act2(); act3()" — пишите:

В комментариях не забывайте ставить пробел после знака «#».

PEP 8 и имена объектов в Python

Если хотите назвать переменную одним символом, избегайте строчной латинской l («эль»), заглавной I («ай») и заглавной O — в некоторых шрифтах они неотличимы от цифр 1 и 0 соответственно. С заглавной L таких проблем нет.

Объекты разного типа должны отличаться и по формату записи имён. Так читатель быстрее понимает, что перед ним. Называйте:

Классы и исключения — LikeThis

Переменные и аргументы — like_this

Функции и методы — тоже like_this, но допускается и likeThis, если вы дописываете старый или чужой код, где уже задан такой формат.

Если имя аргумента вашей функции совпадает с зарезервированным в Python словом, не искажайте написание, но ставьте подчёркивание в конце. Вот так: "input_".

Проверка истинности без знаков равенства

Не используйте два знака равенства (==) для проверки булевых значений. Вместо этого используйте if или if not с именем объекта (например, переменной):

Если нужно сравнить что-то со значением "None", вместо операторов сравнения используйте is/is not .

Помните, что пустые списки, кортежи и последовательности по умолчанию хранят значение false .

Другое важное о Python в PEP 8

В руководстве по стилю есть рекомендованный порядок импорта модулей: сначала грузите модули стандартной библиотеки, затем — из сторонних библиотек, в конце — ваши собственные модули.

При обработке исключений используйте синтаксис привязки имён, равно совместимый с Python 2 и 3:

Старайтесь минимизировать количество кода в конструкциях try… except. Это поможет избежать трудных в обнаружении ошибок.

По возможности выбирайте синтаксис, который работает для всех реализаций Python: CPython, Jython, PyPy и других.

Автоматическая PEP проверка Python-кода

Пока вы создаете маленькие проекты, вычитывать код на ошибки и нарушения стиля не проблема. В работе над большими проектами выручат скрипты автоматической проверки кода . PyCharm проверяет написанное «на лету». А если нужно поработать без IDE? На GitHub есть целый раздел Python Code Quality Authority , где хранятся утилиты для повышения качества кода, в том числе для проверки стиля на соответствие PEP 8: flake8 , pycodestyle , pep8-naming . Когда будет нужно, вы сможете интегрировать Flake8 в свою среду разработки.

Осознанная необходимость

Помните, что знать PEP 8 вы обязаны, а следовать ему — не всегда. Отступы придётся соблюдать, иначе интерпретатор откажется выполнять ваш код. Но в самом руководстве указаны случаи, когда разработчик по своему усмотрению может и должен нарушать рекомендации.

Если конкретный код при подгонке под стиль становится уродливым, «такой хоккей нам не нужен». Например, если разбивка на строки по 72 символа усложняет чтение, PEP 8 предлагает удлинить строку до 80 или даже 100 символов — в зависимости от того, что удобно вам и вашей команде разработки. Чёткие ограничения действуют только для публичных проектов-библиотек. Дополнительное чтение: если вы вошли во вкус, добавьте в свой список ещё и статью « Пиши как настоящий Питонист: идиоматика Python» . Также советуем просмотреть вебинар о применении Python в реальном мире.