pep 8 руководство по написанию кода на python

Самоучитель

PEP 8

Python, подобно живому организму, развивается и приобретает новые возможности благодаря многочисленному международному сообществу согласно определенным правилам и стандартам PEP. PEP – Python Enhancement Proposal, предложения по развитию Python. Эти стандарты позволяют создавать унифицированную проектную документацию для новых утвержденных возможностей языка Python. Самый известный PEP имеет восьмой порядковый номер. PEP8 содержит перечень принципов написания красивого и лаконичного программного кода на языке Python.

Под названием каждого подраздела главы будет находиться по одному из 19 принципов философии Python (Zen of Python). Попытайтесь «прочувствовать» то, что имел в виду автор. Также, если хочется, вместо русской адаптации этих постулатов, увидеть оригинальный текст Тима Петерса, можно запустив вот такую программу.

Для чего придуман PEP8?

(Читаемость имеет значение)

PEP8 существует, чтобы улучшить “читабельность„ кода. Но почему этот параметр имеет настолько большую важность? Почему написание хорошо читаемого кода – один из фундаментальных принципов языка Python?

Как сказал создатель Python, Гвидо Ван Россум: «Код читается гораздо чаще, чем пишется». Вы можете провести несколько минут, или весь день, в процессе написания куска кода для, к примеру, аутентификации пользователя. Написав его, однажды, вы не будете писать его еще раз. Но вы точно вернетесь, чтобы прочитать его еще и еще раз. Эта часть кода может быть частью проекта, над которым вы работаете. Каждый раз, возвращаясь к этому файлу, придется вспомнить, что этот код делает и почему вы написали это именно так.

Если вы начинающий программист Python, вам может быть тяжело запомнить, что делает определенная часть кода по прошествии нескольких дней после ее написания. Однако, если вы будете следовать рекомендациям PEP8, можете быть уверены, ваш код будет в полном порядке. Вы будете знать, что добавили достаточно пробелов, в соответствии с разделением на логические блоки кода.

Соблюдение PEP8 особенно важно, если вы в поисках вакансии python-разработчика. Чистый и читаемый код показывает высокий профессионализм. Он говорит работодателю о вашем понимании правильного структурирования программного кода.

Если же вы более опытный Python-программист, тогда с помощи PEP8 можно с легкостью объединиться с другими программистами для работы над одной задачей. Хорошо читаемый код имеет в данном случае особую критичность. Люди, ранее не видевшие вас, но знакомые с вашим кодом, будут читать, понимая идею, которую вы хотели донести.

Негласная договоренность об именах

(Явное лучше, чем неявное)

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

Не использовать одиночные буквы l, O, или I в качестве каких‑либо имен из‑за риска спутать их с 1 и 0, в зависимости от шрифта.

Стили именования

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

ТипСоглашение об именованииПримеры
ФункцииИспользуйте слово или слова в нижнем регистре. Для удобства чтения разделяйте слова подчеркиванием.function, my_function
ПеременныеИспользуйте одну строчную букву, слово или слова. Для удобства чтения разделяйте слова подчеркиванием.x, var, my_variable
КлассыКаждое слово начинайте с заглавной буквы. Не разделяйте слова подчеркиванием. Этот стиль называется «дело верблюда».Model, MyClass
МетодыИспользуйте слово или слова в нижнем регистре. Для удобства чтения разделяйте слова подчеркиванием.class_method, method
КонстантыИспользуйте одну заглавную букву, слово или слова. Для удобства чтения разделяйте слова подчеркиванием.CONSTANT, MY_CONSTANT, MY_LONG_CONSTANT
МодулиИспользуйте короткие слова или слова в нижнем регистре. Для удобства чтения разделяйте слова подчеркиванием.module.py, my_module.py
ПакетыИспользуйте короткие слова или слова в нижнем регистре. Не разделяйте слова подчеркиванием.package, mypackage

Помимо выбора правильных стилей именования в вашем коде, вы также должны тщательно выбирать сами имена. Ниже приведены несколько советов, как сделать это максимально эффективно.

Правильный выбор имени

Выбор имен для переменных, функций, классов и т. д. может оказаться неожиданно сложной задачей. При написании кода вы должны хорошо продумать свой выбор имен, так как это сделает ваш код более читаемым. Лучший способ назвать ваши объекты в Python — использовать описательные имена, чтобы было понятно, что представляет собой объект.

При именовании переменных у вас может возникнуть соблазн выбрать простые, состоящие из одной буквы имена в нижнем регистре, например x. Но если вы не используете x в качестве аргумента математической функции, непонятно, что представляет собой этот самый x. Представьте, что вы храните имя человека в виде строки и хотите использовать срез строки, чтобы по‑другому отформатировать его имя.

Вы можете получить что‑то вроде этого:

Это будет работать, но вам нужно будет отслеживать, что представляют собой x, y и z. Это также может сбивать с толку соавторов. Более правильный выбор имен будет примерно таким:

Точно так же, чтобы уменьшить количество набираемых вами букв, может возникнуть соблазн использовать сокращения при выборе имен. В приведенном ниже примере была определена функция db, которая принимает единственный аргумент x и удваивает его:

На первый взгляд, это может показаться очевидным выбором — это ведь отличное сокращением для double! Но представьте, что вернетесь к этому коду через несколько дней. Скорее всего, вы забудете, какой смысл вкладывали в эту функцию и вполне можете подумать, что это сокращение от database.

Следующий пример еще более понятен:

Та же самая философия относится и ко всем прочим типам данных и объектов в Python. Всегда пробуйте использовать наиболее емкие и лаконичные названия.

Расположение кода

(Красивое лучше, чем уродливое)

То, как Вы расположите ваш код, имеет огромную роль в повышении его читаемость. В этом разделе вы узнаете, как добавить вертикальные пробелы для улучшения восприятия вашего кода. Вы также узнаете, как правильно пользоваться ограничением в 79 символов на строку, рекомендованным в PEP8.

Монолитный код может быть труден для восприятия. Точно так же, слишком много пустых строк в коде делает его очень разреженным, что заставит читателя пролистывать его чаще, чем необходимо. Ниже приведены три основных правила использования вертикальных пробелов.

Окружите функции и классы верхнего уровня двумя пустыми строками. Функции и классы верхнего уровня должны быть самодостаточны и обрабатывать отдельные функции. Имеет смысл разместить вокруг них дополнительное вертикальное пространство, чтобы было ясно, что они разделены:

Обособьте определения методов внутри классов одной пустой строкой. Внутри класса все функции связаны друг с другом. Рекомендуется оставлять между ними только одну строку:

Используйте пустые строки внутри функций, чтобы четко показать шаги. Иногда сложная функция должна выполнить несколько шагов перед оператором return. Чтобы помочь читателю понять логику внутри функции, может быть полезно оставлять пустую строку между каждым шагом.

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

Если вы правильно используете вертикальные пробелы, это может значительно улучшить читаемость вашего кода и помочь читателю визуально понять, что этот код делает.

Максимальная длина строки и разрыв строки

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

Конечно, не всегда возможно обеспечить длины всех операторов до 79 символов. PEP8 также описывает способы, позволяющие операторам занимать несколько строк. Python предполагает наличие продолжения строки, если код заключен в круглые, квадратные или фигурные скобки:

Если продолжение строки использовать не представляется возможным, можно также использовать обратную косую черту для разрыва строки:

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

Отступы

(Должен быть один очевидный способ сделать это)

Отступы или же пробелы в начале строки — крайне важная часть в синтаксисе Python. Как группируются операторы друг с другом операторы, в Python определяют именно уровни строк.

Отступ перед оператором вывода дает сигнал Python об условном выполнении только в случае, когда оператор if возвращает True. Ровно такой же отступ покажет Python, какой именно код выполнять при вызове функции или какой код имеет отношение к данному классу. Ключевых правил расстановки отступов всего два и они ниже:

Используйте четыре последовательных пробела для отступа;

Отдавайте предпочтение пробелам, а не табуляции.

Пробелы против Табуляции

Вы можете настроить ваш редактор кода на вставку четырех пробелов, когда вы нажимаете клавишу Tab. Также необходимо иметь в виду, что в Python 3 запрещено смешение пробелов и табуляции. Изначально выберите, как именно вы будете выставлять отступы и придерживайтесь этого выбора. Иначе, вместо выполнения кода, вы получите ошибку.

Комментарии

(Если реализацию трудно объяснить, это была плохая идея)

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

Используйте длину комментариев при документации не более 72 символов;

Не используйте сокращения, начинайте предложения с заглавной буквы;

Не забывайте актуализировать комментарии, при изменении кода.

Пример простейшего комментария:

Пробелы в выражениях и утверждениях

(Разреженное лучше, чем плотное)

Полезность пробелов в выражениях и операторах трудно переоценить. Если пробелов недостаточно, код может быть трудночитаемым, так как все сгруппированы вместе. Если пробелов слишком много, может быть сложно визуально объединить строки кода в, логически связанные, блоки.

Окружите следующие бинарные операторы одним пробелом с каждой стороны:

Источник

PEP 8: каким должен быть код на Python

Python имеет определенные стандарты кода, которым стараются следовать все программисты. Эти стандарты описаны в документации PEP8.

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

Почему важно стандартизировать код?

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

Если каждый программист будет писать код с разным стилем, то его анализ станет очень трудной задачей. Поэтому важно, чтобы Python-разработчики следовали определенным соглашениям, которые позволяют стандартизировать код, сделать его более понятным любому специалисту.

Рекомендации по созданию красивого кода на Python не определяют стиль кода полностью. Поэтому программист может делать некоторые вещи на своё усмотрение, однако он всё ещё должен следовать тем указаниям, которые определены в стандарте.

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

Разметка кода на Python

Этот раздел содержит указания, определяющие, как оформлять код на Python 3 (пробелы, отступы, строки).

Отступы

Для обозначения нового уровня вложенности используется четыре пробела.

При разделении аргументов функции на несколько строк размер отступа может быть разным.

Если это объявление или вызов функций (нет тела функции), то можно либо выравнивать следующие строки по открывающейся скобке:

либо использовать четыре пробела, но с обязательным переносом первой строки:

Если после списка аргументов следует еще какой-либо код (например, если это объявляется функция), то к отступу аргументов добавляется еще 4 пробела:

Это делается для того, чтобы отделить аргументы от тела функции.

В случае с оператором if, программист может как использовать, так и не использовать экстра отступы:

Если не использовать дополнительные пробелы, то, при желании, можно отделить тело условного оператора однострочным комментарием. Это может улучшить читаемость в некоторых редакторах кода из-за подсветки комментария.

Закрывающая конструкция в функции или структуре может располагаться под первым символом нижней строки:

Также её можно поместить в самое начало строки:

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

Максимальная длина строки

Благодаря этим ограничениям программисты могут открывать сразу несколько файлов с кодом на одном экране, комфортно работать на маленьких экранах (ультрабуки, нетбуки) и легко понимать код.

Круглые скобки — лучший способ реализовать разделение кода на несколько строк. Однако программисты также могут использовать знак обратной косой черты « \ «.

Бинарные операторы и пробелы

Кроме того, если операторы используются в многострочном выражении, то они всегда должны переноситься вместе с правым операндом:

Пустые строки

Определения внешних классов и функций окружается двумя пустыми строками (две строки сверху).

Методы внутри класса отделяются одной пустой строкой.

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

Нельзя использовать пустые строки между внешним и вложенным блоком кода.

Кодировка

Если нужно использовать символы других кодировок, следует пользоваться экранирующими последовательностями: \x, \u, \U, \N.

Импорт

Импорт каждого нового модуля должен происходить в новой строке:

При импорте нескольких частей модуля можно писать их в одной строке через запятую:

Подключение модулей всегда находятся в начале файла, ниже строк документации и выше объявления констант.

Импорты должны быть разделены по группам, между которыми ставится пустая строка:

Использовать «*» при импорте считается плохим тоном. Дело в том, что такой импорт не дает представления об именах, которые находятся в импортированном пространстве имен, что не только сбивает с толку, но и может привести к ошибкам.

Кавычки в строках

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

Для строк документации обязательно используется три двойных кавычки. Более подробнее это описано в стандарте PEP 257.

Пробелы в выражениях и операторах

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

Использование запятых

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

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

Комментарии

Комментарии — это важная часть любого проекта, потому что с их помощью можно понять, как работает код и какие особенности он имеет. Программисты использую комментарии не только для того, чтобы другие специалисты могли понять код, но и чтобы самим не забыть, как и зачем они реализовали те или иные функции.

Комментарии должны отражать суть кода, а не противоречить ему. Если код по какой-то причине изменяется, комментарии также необходимо изменить.

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

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

Блочные комментарии

Блочные комментарии используются, когда необходимо объяснить действий какого-либо блока кода. Как правило, такие комментарии размещаются над блоком кода на отдельной строке.

Комментарии «в строке»

Это комментарии, которые объясняют действия строки кода и пишутся в той же строке, что и код. Они должны отделяться от кода не менее чем двумя пробелами.

Такие комментарии не рекомендуется использовать, потому что в большинстве случаев они объясняют очевидные вещи и не несут никакой практической пользы.

Однако в некоторых случаях они могут быть полезны, когда настоящее назначение строки не очевидно:

Строки документации

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

Более подробно про соглашение о документации рассказано в PEP 257. Кавычки, показывающие окончания строк документации, должны переносится на новую строку.

Однако, если документация состоит из одной строки, то кавычки не переносятся.

Правила по выбору имён

Соглашения по выбору имён в Python неточны, поэтому не существует списка, полностью определяющего стиль наименований в Python. Для всех новых пакетов и модулей должен использоваться текущий стандарт наименований.

Главный принцип

Если имя является открытой частью интерфейса прикладного программирования, то оно должно отражать не реализацию, а использование.

Стили имен

Выбирать имена в Python можно в соответствии с одним из многих стилей. Определить, какой стиль наименования используется, можно независимо от того, для чего он используется.

Обычно используются следующие стили:

Имена, которые лучше не использовать

Никогда не используйте строчные английские буквы: l («эл»), O (заглавная «о») и I (заглавная «ай»). Заглавная «о» неотличима от нуля, а «l» и «I» друг от друга.

Если всё же возникла необходимость использовать l («эл»), замените её на заглавную «L».

Имена пакетов и моделей

Модули должны иметь короткие имена в нижнем регистре. В именах модулей допускается использовать нижние подчеркивания, если это улучшает читаемость.

Если модуль на C или C++ сопровождается модулем Python, обеспечивающим более высокоуровневый интерфейс, то имя C/C++ модуля начинается с символа нижнего подчеркивания (_modulename).

Имена классов

Классам дают имена в соответствии со стилем наименования CapitalizedWords.

Имена исключений

Из-за того что исключения по сути являются классами, к ним применяется то же соглашение об наименованиях, что и для классов.

Программист может добавить суффикс «Error», чтобы подчеркнуть, что исключение является ошибкой.

Имена глобальных переменных

Глобальные переменные именуются по тем же соглашениям, что и функции. Кроме того, глобальные переменные стоит использовать только в пределах одного модуля.

__all__ — это список доступных для импорта объектов, то есть публичных.

Имена функций и переменных

Для имен функций используется нижний регистр. Если необходимо повысить читаемость, можно разделять слова символом нижнего подчеркивания.

Имена переменных выбираются по тем же правилам, что и имена функций.

В случаях, если требуется сохранить обратную совместимость с библиотекой (например, threading.py), допускается использовать mixedCase.

Имена аргументов функций и методов

Для методов экземпляра в качестве первого аргумента всегда используется self, а для методов класса — cls.

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

Имена переменных и методов экземпляров класса

Тот же стиль, что и для функций: нижний регистр и нижние подчеркивания при необходимости.

Константы

Константы определяются на уровне подключения модулей и пишутся в верхнем регистре с разделением слова символами подчеркивания.

Источник

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

pep 8 руководство по написанию кода на python

pep 8 руководство по написанию кода на python

pep 8 руководство по написанию кода на python

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

pep 8 руководство по написанию кода на python

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

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

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *