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

PEP против «свинок» от программирования. Что нужно знать каждому, кто пишет на Python.
21 декабря 2017Cbc0f0509128ea8a7487ec71c1240fb531db396bМария Лисянская4262421

В борьбе за красивый и понятный код 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. Если по какой-то причине вам очень нужна «альтернативная» кодировка исходника, обязательно укажите её в комментарии в первой строке файла:


# coding: cp1251
print("Текст в кодировке Windows 1251.")
input()

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

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

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

if sunny:
    print("The sun is shining!")
else:
    pass

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

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

Интересный факт: исследование 2017 года на Stack Overflow показало, что программисты, которые делают отступы пробелами, зарабатывают почти на 9% больше, чем любители Tab'а.

Когда пробелы в Python не ставят

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

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

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

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

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

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

x = (y + 1) * (y — a)

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

act1()
act2()
act3()

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

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

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

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

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

  • Константы  —  LIKE_THIS

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

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

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

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

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

 if  i_have_apples:
# делаем то
 if not  key_obtained:
# делаем это

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

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

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

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

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

try:
    something()
except Exception as exc:
    raise AnotherDamnError(str(exc))

 

  • Старайтесь минимизировать количество кода в конструкциях  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 в реальном мире.

Новые комментарии

Спасибо,
что читаете наш блог!
Posts popup