4.1 Пробелы и скобки
4.1.1 Не ставьте пробелы внутри каких-либо скобок (обычных, фигурных и квадратных).
4.1.2 Никаких пробелов перед открывающей скобкой, которая начинает список аргументов, индекс или срез.
Рекомендуется использовать 4 пробела на каждый уровень отступа. Python 3 запрещает смешивание табуляции и пробелов в отступах. Код, в котором используются и те, и другие типы отступов, должен быть исправлен так, чтобы отступы в нем были расставлены только с помощью пробелов.
Не разделяйте ваши строки с помощью точек с запятой и не используйте точки с запятой для разделения команд, находящихся на одной строке.
Используйте скобки экономно. Не используйте их с выражением return
или с условной конструкцией, если не требуется организовать перенос строки. Однако скобки хорошо использовать для создания кортежей.
4.1.1 Не ставьте пробелы внутри каких-либо скобок (обычных, фигурных и квадратных).
4.1.2 Никаких пробелов перед открывающей скобкой, которая начинает список аргументов, индекс или срез.
4.2.1 Перед запятой, точкой с запятой либо точкой не должно быть никаких пробелов. Используйте пробел после запятой, точки с запятой или точки (кроме того случая, когда они находятся в конце строки).
4.3.1 Окружайте бинарные операторы одиночными пробелами с каждой стороны. Это касается присваивания (=
), операторов сравнения (==
, <
, >
, !=
, <>
, <=
, >=
, in
, not in
, is
, is not
), и булевых операторов (and
, or
, not
). Используйте, как вам покажется правильным, окружение пробелами по отношению к арифметическим операторам, но расстановка пробелов по обеим сторонам бинарного оператора придает целостность коду.
4.3.2 Не используйте более одного пробела вокруг оператора присваивания (или любого другого оператора) для того, чтобы выровнять его с другим.
4.3.3 Не используйте пробелы по сторонам знака =
, когда вы используете его, чтобы указать на именованный аргумент или значение по умолчанию.
Ограничивайте длину строк 79 символами (а длину строк документации и комментариев — 72 символами). В общем случае не используйте обратный слеш в качестве перехода на новую строку. Используйте доступное в Python явное объединение строк посредством круглых и фигурных скобок. Если необходимо, можно добавить дополнительную пару скобок вокруг выражения.
Если ваш текст не помещается в одну строку, используйте скобки для явного объединения строк.
Что касается длинных URL в комментариях, то располагайте их, если это необходимо, на одной строке.
Обратный слеш иногда используется. Например, с длинной конструкцией with
для переноса блока инструкций.
Ещё один подобный случай — длинные assert
.
Отделяйте функции (верхнего уровня, не функции внутри функций) и определения классов двумя пустыми строками. Определения методов внутри класса отделяйте одной пустой строкой. Две пустые строки должны быть между объявлениями верхнего уровня, будь это класс или функция. Одна пустая строка должна быть между определениями методов и между объявлением класса и его первым методом.
import os
.
.
class MyClass:
.
def __init__(self):
self.name = 'My name'
.
def f(self):
return 'hello world'
.
.
def MyFunc():
i = 12345
return i
.
myclass = MyClass()
Используйте (без энтузиазма) пустые строки в коде функций, чтобы отделить друг от друга логические части.
Python расценивает символ control+L
как незначащий (whitespace), и вы можете использовать его, потому что многие редакторы обрабатывают его как разрыв страницы — таким образом, логические части в файле будут на разных страницах. Однако не все редакторы распознают control+L
и могут на его месте отображать другой символ.
Имена, которых следует избегать:
l
(маленькая латинская буква «эль»), O
(заглавная латинская буква «о») или I
(заглавная латинская буква «ай») как однобуквенные идентификаторы. В некоторых шрифтах эти символы неотличимы от цифры один и нуля. Если очень нужно l
, пишите вместо неё заглавную L
.Имена функций должны состоять из маленьких букв, а слова разделяться символами подчеркивания — это необходимо, чтобы увеличить читабельность.
Стиль mixedCase допускается в тех местах, где уже преобладает такой стиль — для сохранения обратной совместимости.
Модули должны иметь короткие имена, состоящие из маленьких букв. Можно использовать символы подчёркивания, если это улучшает читабельность. То же самое относится и к именам пакетов, однако в именах пакетов не рекомендуется использовать символ подчёркивания.
Так как имена модулей отображаются в имена файлов, а некоторые файловые системы являются нечувствительными к регистру символов и обрезают длинные имена, очень важно использовать достаточно короткие имена модулей — это не проблема в Unix, но, возможно, код окажется непереносимым в старые версии Windows, Mac, или DOS.
Все имена классов должны следовать соглашению CapWords почти без исключений.
class MyFirstClass:
Иногда вместо этого могут использоваться соглашения для именования функций, если интерфейс документирован и используется в основном как функции.
Обратите внимание, что существуют отдельных соглашения о встроенных именах: большинство встроенных имен — одно слово (либо два слитно написанных слова), а соглашение CapWords используется только для именования исключений и встроенных констант.
Так как исключения являются классами, к исключениями применяется стиль именования классов. Однако вы можете добавить Error в конце имени (если, конечно, исключение действительно является ошибкой).
Константы обычно объявляются на уровне модуля и записываются только заглавными буквами, а слова разделяются символами подчеркивания.
MAX_OVERFLOW = 10
TOTAL = 100
Если нам необходимо в цикле пройти по всем элементам списка, то хорошим тоном (да и более читаемым) будет такой способ:
И хотя бывалые программисты или просто любители C могут использовать и такой код, это моветон.
А если нужно пройти по списку задом наперед, то лучше всего использовать метод reversed:
Вместо того чтобы писать избыточный код, который и читается-то не очень внятно.
Если есть необходимость пройти в цикле по ряду чисел, то метод range будет намного приемлемее, как минимум потому, что этот метод потребляет намного меньше памяти, чем вариант в блоке "Плохо". А представьте, что у вас ряд из трёх миллиардов последовательных чисел!
Метод enumerate позволяет получить сразу индекс и значение из списка, что, во-первых, предоставляет множество возможностей для дальшнейшего проектирования, а во-вторых, такой код легче читается и воспринимается.
Используя метод zip, мы получаем из двух списков один список кортежей, что более удобно для дальнейшего использования и требует меньше памяти. Да и просто этот вариант более элегантный.
Каждый импорт, как правило, должен быть на отдельной строке.
В то же время, можно писать так:
Импорты всегда располагаются в начале файла, сразу после комментариев уровня модуля, строк документации, перед объявлением констант и объектов уровня модуля. Импорты должны быть сгруппированы в порядке от самых простых до самых сложных:
Наряду с группированием, импорты должны быть отсортированы лексикографически, нерегистрозависимо, согласно полному пути до каждого модуля.
Рекомендуется абсолютное импортирование, так как оно обычно более читаемо и ведет себя лучше (или, по крайней мере, даёт понятные сообщения об ошибках), если импортируемая система настроена неправильно (например, когда каталог внутри пакета заканчивается на sys.path
).
Тем не менее, явный относительный импорт является приемлемой альтернативой абсолютному импорту, особенно при работе со сложными пакетами, где использование абсолютного импорта было бы излишне подробным.
Следует избегать шаблонов импортов (from import *
), так как они делают неясным то, какие имена присутствуют в глобальном пространстве имён, что вводит в заблуждение как читателей, так и многие автоматизированные средства.
Рекомендуем также ознакомиться с полной версией соглашения о том, как писать код на Python (PEP 8)
8. Комментарии
Комментарии, противоречащие коду, хуже, чем отсутствие комментариев. Всегда исправляйте комментарии, если меняете код!
Комментарии должны быть законченными предложениями. Если комментарий — фраза или предложение, первое слово должно быть написано с большой буквы, если только это не имя переменной, которая начинается с маленькой буквы (никогда не отступайте от этого правила для имен переменных).
Ставьте два пробела после точки в конце предложения.
Если вы — программист, не говорящий по-английски, то всё равно следует использовать английский язык для написания комментариев. Особенно, если нет уверенности на 120% в том, что этот код будут читать только люди, говорящие на вашем родном языке.
8.1 Блоки комментариев
Блок комментариев обычно объясняет код (весь или только некоторую часть), идущий после блока, и должен иметь тот же отступ, что и сам код. Каждая строчка такого блока должна начинаться с символа
#
и одного пробела после него (если только сам текст комментария не имеет отступа).Абзацы внутри блока комментариев разделяются строкой, состоящей из одного символа
#
.8.2 Комментарии в строке с кодом
Старайтесь реже использовать подобные комментарии.
Такой комментарий находится в той же строке, что и инструкция. «Встрочные» комментарии должны отделяться хотя бы двумя пробелами от инструкции. Они должны начинаться с символа
#
и одного пробела.Комментарии в строке с кодом не нужны и только отвлекают от чтения, если они объясняют очевидное.
8.3 Строки документации
Соглашения о написании хорошей документации (docstrings) зафиксированы в PEP 257.
Пишите документацию для всех публичных модулей, функций, классов, методов. Строки документации необязательны для приватных методов, но лучше написать, что делает метод. Комментарий нужно писать после строки с
def
.Очень важно, чтобы закрывающие кавычки стояли на отдельной строке. А еще лучше, если перед ними будет ещё и пустая строка.
Для однострочной документации можно оставить
"""
на той же строке.