Читай 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. Если по какой-то причине вам очень нужна «альтернативная» кодировка исходника, обязательно укажите её в комментарии в первой строке файла:
# 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 категорически не рекомендует, но с одной оговоркой. Если вы дорабатываете готовый проект, где отступы сделаны табуляцией, придерживайтесь принятого до вас стандарта. Если в коде разнобой, замените всё на пробелы.
Когда пробелы в Python не ставят
-
Сразу после открывающей скобки и перед закрывающей: ( x ) — так не надо.
-
Перед скобками при вызове аргумента. Неправильно: arg (1). Правильно: arg(1).
-
Перед скобками индекса и среза: dict['step'] = map[i].
-
Между именем параметра/аргумента, знаком «=» и значением: 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 в реальном мире.