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-сообществу нужны ориентиры: что такое хорошо и что такое плохо. Создатель языка Гвидо ван Россум (Guido van Rossum) и его соратник Барри Уорсо (Barry Warsaw) описали хороший стиль Py-кода в документе PEP 8.
Краткий обзор PEP 8 ниже поможет вам ориентироваться в руководстве. Но это ни в коем случае не альтернатива оригиналу, который во время занятий Python хорошо бы держать под рукой.
Зачем нужен PEP 8
Единый стиль оформления делает код понятным для самого программиста и его коллег с разным уровнем подготовки.
В идеале наиболее сложный фрагмент кода должен быть понятен с первого прочтения. Это упрощает командную разработку и обучение новичков, позволяет вам быстро возвращаться к собственным давним проектам.
PEP 8 затрагивает структуру и внешний вид кода:
выбор кодировки исходного кода;
группировку инструкций по импорту модулей;
максимальную длину строки кода — рекомендуется до 79 знаков, а для строк документации (docstring) — 72 знака;
использование отступов — табуляции и пробелов;
использование пустых строк для разбивки кода на блоки и выделения функций верхнего уровня;
именование переменных, констант, классов и экземпляров, функций, аргументов, модулей, пакетов;
выбор уровня доступности классов и методов (public, private, API-подклассы), а также порядка их наследования.
Без этого комментария интерпретатор выдаст ошибку.
PEP 8: Питону важны отступы
Теоретически вы можете использовать иное число пробелов: 2, 8 и т.д. Главное, чтобы оно совпадало по всему коду — иначе интерпретатор будет ругаться. Но 4 — «золотой стандарт» сообщества: быстро ставить, привычно читать.
В чужом коде вам может встретиться другой вид отступа — табуляция. Его PEP 8 категорически не рекомендует, но с одной оговоркой. Если вы дорабатываете готовый проект, где отступы сделаны табуляцией, придерживайтесь принятого до вас стандарта. Если в коде разнобой, замените всё на пробелы.
Когда пробелы в Python не ставят
Сразу после открывающей скобки и перед закрывающей: ( 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 с именем объекта (например, переменной):
Другое важное о Python в PEP 8
В руководстве по стилю есть рекомендованный порядок импорта модулей: сначала грузите модули стандартной библиотеки, затем — из сторонних библиотек, в конце — ваши собственные модули.
При обработке исключений используйте синтаксис привязки имён, равно совместимый с Python 2 и 3:
Старайтесь минимизировать количество кода в конструкциях try… except. Это поможет избежать трудных в обнаружении ошибок.
По возможности выбирайте синтаксис, который работает для всех реализаций Python: CPython, Jython, PyPy и других.
Автоматическая PEP проверка Python-кода
Осознанная необходимость
Помните, что знать PEP 8 вы обязаны, а следовать ему — не всегда. Отступы придётся соблюдать, иначе интерпретатор откажется выполнять ваш код. Но в самом руководстве указаны случаи, когда разработчик по своему усмотрению может и должен нарушать рекомендации.
В борьбе за красивый и понятный код Python-сообществу нужны ориентиры: что такое хорошо и что такое плохо. Создатель языка Гвидо ван Россум (Guido van Rossum) и его соратник Барри Уорсо (Barry Warsaw) описали хороший стиль Py-кода в документе PEP 8.
Краткий обзор PEP 8 ниже поможет вам ориентироваться в руководстве. Но это ни в коем случае не альтернатива оригиналу, который во время занятий Python хорошо бы держать под рукой.
Зачем нужен PEP 8
Единый стиль оформления делает код понятным для самого программиста и его коллег с разным уровнем подготовки.
В идеале наиболее сложный фрагмент кода должен быть понятен с первого прочтения. Это упрощает командную разработку и обучение новичков, позволяет вам быстро возвращаться к собственным давним проектам.
PEP 8 затрагивает структуру и внешний вид кода:
выбор кодировки исходного кода;
группировку инструкций по импорту модулей;
максимальную длину строки кода — рекомендуется до 79 знаков, а для строк документации (docstring) — 72 знака;
использование отступов — табуляции и пробелов;
использование пустых строк для разбивки кода на блоки и выделения функций верхнего уровня;
именование переменных, констант, классов и экземпляров, функций, аргументов, модулей, пакетов;
выбор уровня доступности классов и методов (public, private, API-подклассы), а также порядка их наследования.
Без этого комментария интерпретатор выдаст ошибку.
PEP 8: Питону важны отступы
Теоретически вы можете использовать иное число пробелов: 2, 8 и т.д. Главное, чтобы оно совпадало по всему коду — иначе интерпретатор будет ругаться. Но 4 — «золотой стандарт» сообщества: быстро ставить, привычно читать.
В чужом коде вам может встретиться другой вид отступа — табуляция. Его PEP 8 категорически не рекомендует, но с одной оговоркой. Если вы дорабатываете готовый проект, где отступы сделаны табуляцией, придерживайтесь принятого до вас стандарта. Если в коде разнобой, замените всё на пробелы.
Когда пробелы в Python не ставят
Сразу после открывающей скобки и перед закрывающей: ( 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 с именем объекта (например, переменной):
Другое важное о Python в PEP 8
В руководстве по стилю есть рекомендованный порядок импорта модулей: сначала грузите модули стандартной библиотеки, затем — из сторонних библиотек, в конце — ваши собственные модули.
При обработке исключений используйте синтаксис привязки имён, равно совместимый с Python 2 и 3:
Старайтесь минимизировать количество кода в конструкциях try… except. Это поможет избежать трудных в обнаружении ошибок.
По возможности выбирайте синтаксис, который работает для всех реализаций Python: CPython, Jython, PyPy и других.
Автоматическая PEP проверка Python-кода
Осознанная необходимость
Помните, что знать PEP 8 вы обязаны, а следовать ему — не всегда. Отступы придётся соблюдать, иначе интерпретатор откажется выполнять ваш код. Но в самом руководстве указаны случаи, когда разработчик по своему усмотрению может и должен нарушать рекомендации.
Правила оформления кода по PEP8 на Python. Руководство для программиста
Введение в PEP8 (Python Enhancement Proposal #8)
Документ Python Enhancement Proposal #8 (сокращенно РЕР8) содержит предложения по стилевому оформлению кода программ на языке Python. Вообще говоря, вы вправе форматировать свой код так, как считаете нужным. Однако применение единообразного стиля облегчит изучение кода другими людьми и улучшит его удобочитаемость. Совместное использование общего стиля с другими Руthоn-программистами в рамках большого сообщества способствует улучшению качества программ при коллективной работе над проектами. Но даже если единственный человек, который когда-либо будет читать ваш код, — это вы, соблюдение рекомендаций РЕР 8 облегчит внесение последующих изменений в код.
Документ РЕР8 содержит детализированные правила написания кода на Python. По мере развития языка этот документ постоянно обновляется. Было бы неплохо, если бы вы прочитали целиком все руководство
Ниже приведены некоторые правила, которых следует обязательно придерживаться.
Пробелы
В языке Python пробелы имеют синтаксическое значение. Особое значение Pythоn-программисты придают влиянию пробелов на удобочитаемость кода.
Имена
В документе РЕР8 для различных элементов языка предлагается свой стиль имен. Благодаря этому можно легко определить в процессе чтения кода, какому типу соответствует то или иное имя:
Выражения и инструкции
Одно из положений дзен-философии Python гласит: «Должен существовать один — и предпочтительно только один — очевидный способ сделать это». В рекомендациях документа РЕР8 предпринимается попытка кодифицировать такой стиль написания выражений и предложений.
В каждом подразделе модули должны располагаться в алфавитном порядке.
Что следует запомнить
Best Practices Python PEP8 Code Style — Стиль кода для написания функций
Если вы спросите программистов Python, что им больше всего нравится в Python, они часто будут ссылаться на его высокую читабельность. Действительно, высокий уровень читабельности лежит в основе дизайна языка Python, следуя общепризнанному факту, что код читается гораздо чаще, чем пишется.
Одной из причин высокой читабельности кода Python является его полный набор рекомендаций PEP8 по стилю кода и «Pythonic» идиом.
Когда ветеран Python-разработчик (Pythonista) называет части кода не «Pythonic», они обычно означают, что эти строки кода не следуют общим правилам и не выражают свое намерение в том, что считается лучшим (слушайте: наиболее читаемый) путь.
В некоторых случаях не было достигнуто соглашения о том, как выразить намерение в коде Python, но такие случаи редки.
Явный код
Хотя в Python возможен любой вид черной магии, наиболее явный и простой способ предпочтителен.
Плохо
Хорошо
В приведенном выше хорошем коде x и y явно принимаются от вызывающей стороны, и возвращается явный словарь. Разработчик, использующий эту функцию, точно знает, что делать, читая первые и последние строки, что не так с плохим примером.
Одно утверждение на строку
Несмотря на то, что некоторые составные операторы, такие как списочные выражения, допускаются и ценятся за их краткость и выразительность, использование двух разделенных операторов в одной строке кода является плохой практикой.
Плохо
Хорошо
Аргументы функции
Аргументы могут быть переданы в функции четырьмя различными способами.
Программист должен написать функцию, чтобы определить, какие аргументы являются позиционными аргументами, а какие — необязательными аргументами ключевых слов, и решить, использовать ли передовые методы передачи произвольных аргументов. Если следовать приведенному выше совету разумно, можно и приятно писать функции Python, которые:
Избегайте волшебной палочки
Мощный инструмент для хакеров, Python поставляется с очень богатым набором хуков и инструментов, позволяющих вам выполнять практически любые хитрые трюки. Например, можно выполнить каждое из следующих действий:
Тем не менее, все эти варианты имеют много недостатков, и всегда лучше использовать самый простой способ для достижения вашей цели. Основным недостатком является то, что читаемость сильно страдает при использовании этих конструкций. Многие инструменты анализа кода, такие как pylint или pyflakes, не смогут проанализировать этот «волшебный» код.
Мы считаем, что разработчик Python должен знать об этих почти безграничных возможностях, потому что это вселяет уверенность в том, что на пути не будет непроходимых проблем. Однако очень важно знать, как и, в частности, когда их не использовать.
Подобно мастеру кунг-фу, питонист знает, как убивать одним пальцем, и никогда не делать этого на самом деле.
Мы все ответственные пользователи
Как видно выше, Python допускает множество трюков, и некоторые из них потенциально опасны. Хорошим примером является то, что любой клиентский код может переопределять свойства и методы объекта: в Python нет ключевого слова «private». Эта философия, очень отличающаяся от языков с высокой степенью защиты, таких как Java, которые предоставляют множество механизмов для предотвращения любого неправильного использования, выражается высказыванием: «Мы все ответственные пользователи».
Это не означает, что, например, никакие свойства не считаются закрытыми и что правильная инкапсуляция невозможна в Python. Скорее, вместо того, чтобы полагаться на бетонные стены, возводимые разработчиками между их кодом и чужим, сообщество Python предпочитает полагаться на ряд соглашений, указывающих, что к этим элементам не следует обращаться напрямую.
Основное соглашение для частных свойств и деталей реализации заключается в добавлении префикса ко всем «внутренним элементам». Если клиентский код нарушает это правило и получает доступ к этим отмеченным элементам, любое неправильное поведение или проблемы, возникшие при изменении кода, являются ответственностью клиентского кода.
Использование этого соглашения приветствуется: любой метод или свойство, которые не предназначены для использования клиентским кодом, должны начинаться с подчеркивания. Это гарантирует лучшее разделение обязанностей и более легкую модификацию существующего кода; всегда будет возможно обнародовать частную собственность, но сделать публичную собственность частной может быть гораздо более сложной операцией.
Возвращение значения
Когда функция усложняется, нередко используют несколько операторов return внутри тела функции. Однако, чтобы сохранить четкое намерение и устойчивый уровень читабельности, желательно избегать возврата значимых значений из многих выходных точек в теле.
Существует два основных случая возврата значений в функцию: результат возврата функции, когда она была обработана нормально, и случаи ошибок, которые указывают на неправильный входной параметр, или любую другую причину, по которой функция не может завершить вычисление или задача.
Если вы не хотите вызывать исключения для второго случая, может потребоваться возврат значения, такого как None или False, указывающего, что функция не может работать правильно. В этом случае лучше вернуться, как только был обнаружен неправильный контекст. Это поможет сгладить структуру функции: весь код после оператора return-from-of-error может предполагать, что условие выполнено для дальнейшего вычисления основного результата функции. Наличие нескольких таких операторов возврата часто необходимо.
Однако, когда функция имеет несколько основных точек выхода для своего нормального хода, становится трудно отлаживать возвращаемый результат, поэтому может быть предпочтительнее сохранить одну точку выхода. Это также поможет выделить некоторые пути кода, а несколько точек выхода являются вероятным признаком того, что такой рефакторинг необходим.
Идиомы
Хотя обычно есть один — и предпочтительно только один — очевидный способ сделать это; способ писать идиоматические коды Python могут быть неочевидными для начинающего Python. Таким образом, хорошие идиомы должны быть осознанно приобретены.
Ниже приведены некоторые распространенные идиомы Python:
Распаковка
Если вы знаете длину списка или кортежа, вы можете назначить имена его элементам при распаковке. Например, поскольку enumerate() будет предоставлять кортеж из двух элементов для каждого элемента в списке:
Вы также можете использовать это для замены переменных:
Вложенная распаковка тоже работает:
Создать игнорируемую переменную
Если вам нужно что-то назначить (например, в распаковке ), но вам не понадобится эта переменная, используйте __ :
Многие руководства по стилю Python рекомендуют использовать одно подчеркивание « _ » для одноразовых переменных, а не двойное подчеркивание « __ », рекомендованное здесь.Проблема заключается в том, что « _ » обычно используется в качестве псевдонима для gettext() функции, а также в интерактивном приглашении для хранения значения последней операции.Вместо этого использование двойного подчеркивания является столь же понятным и почти таким же удобным, и исключает риск случайного вмешательства в любой из этих других случаев использования.
Создайте список длины N того же самого
Используйте * оператор списка Python :
Создание списка длины N списков
Поскольку списки являются изменяемыми, * оператор (как указано выше) создаст список из N ссылок на один и тот же список, что вряд ли вам нужно. Вместо этого используйте понимание списка:
Примечание: используйте range () вместо xrange () в Python 3.
Создать строку из списка
Распространенная идиома для создания строк — использовать str.join() пустую строку.
Это установит значение переменной word в «spam». Эта идиома может применяться к спискам и кортежам.
Поиск предмета в коллекции
Иногда нам нужно искать в коллекции вещей. Давайте рассмотрим два варианта: списки и наборы.
Возьмите следующий код для примера:
Из-за этих различий в производительности часто рекомендуется использовать наборы или словари вместо списков в случаях, когда:
Для небольших коллекций или коллекций, в которых вы не часто будете искать, дополнительное время и память, необходимые для настройки хэш-таблицы, часто будут больше, чем время, сэкономленное благодаря улучшенной скорости поиска.
Дзен питона
Соглашения PEP8
Вот некоторые соглашения, которым вы должны следовать, чтобы сделать ваш код легче для чтения.
Проверьте, равна ли переменная постоянной
Вам не нужно явно сравнивать значение с True, None или 0 — вы можете просто добавить его в оператор if. См. Проверка истинности значения для получения списка того, что считается ложным.
Плохо :
Хорошо :
Доступ к элементу словаря
Плохо :
Хорошо :
Короткие способы манипулирования списками
Постижения списков предоставляют мощный и лаконичный способ работы со списками.
Выражения генератора следуют почти тому же синтаксису, что и списки, но возвращают генератор вместо списка.
Создание нового списка требует больше работы и использует больше памяти. Если вы просто собираетесь пройтись по новому списку, используйте вместо этого итератор.
Плохо :
Хорошо :
Используйте списки, когда вам действительно нужно создать второй список, например, если вам нужно использовать результат несколько раз.
Если ваша логика слишком сложна для понимания короткого списка или выражения генератора, рассмотрите возможность использования функции генератора вместо возврата списка.
Хорошо :
Никогда не используйте списочное понимание только для его побочных эффектов.
Плохо :
Хорошо :
Фильтрация списка
Плохо :
Никогда не удаляйте элементы из списка, пока вы просматриваете его.
Не делайте несколько проходов по списку.
Хорошо :
Используйте понимание списка или выражение генератора.
Возможные побочные эффекты изменения исходного списка
Изменение исходного списка может быть рискованным, если на него ссылаются другие переменные. Но вы можете использовать назначение срезов, если вы действительно хотите это сделать.
Изменение значений в списке
Плохо :
Помните, что назначение никогда не создает новый объект. Если две или более переменных ссылаются на один и тот же список, изменение одной из них изменит их все.
Хорошо :
Безопаснее создать новый объект списка и оставить оригинал в покое.
Используйте enumerate() счетчик вашего места в списке.
Читать из файла
Используйте синтаксис для чтения из файлов. Это автоматически закроет файлы для вас. with open
Плохо :
Хорошо :
Продолжение строки
Когда логическая строка кода длиннее допустимого предела, вам необходимо разбить ее на несколько физических строк. Интерпретатор Python объединяет последовательные строки, если последний символ строки является обратной косой чертой. Это полезно в некоторых случаях, но, как правило, его следует избегать из-за его хрупкости: пробел, добавленный в конец строки после обратной косой черты, нарушит код и может привести к неожиданным результатам.
Лучшее решение — использовать круглые скобки вокруг ваших элементов. Оставленный с незакрытой круглой скобкой в конце строки, интерпретатор Python присоединится к следующей строке, пока круглые скобки не будут закрыты. То же самое относится и к фигурным и квадратным скобкам.
Плохо :
Хорошо :
Однако чаще всего разделение длинной логической строки является признаком того, что вы пытаетесь сделать слишком много вещей одновременно, что может ухудшить читабельность.