Если перед программистом стоит задача написать приложение или библиотеку для себя, или если в будущем нет планов привлекать к работе над проектом других людей, то он действительно может делать с кодом все, что захочет . Золотое правило для программистов-одиночек звучит так: «Пока я понимаю свой код, мне больше ничего не нужно делать».

Если программист работает в команде (или такая работа планируется в ближайшее время), возникает необходимость документировать и тестировать исходный код, а также правильно называть переменные, соблюдая руководство по стилю python. Это необходимо для информирования коллег о своих намерениях непосредственно через исходный код. В противном случае проект всегда будет сталкиваться с угрозой возникновения большого количества ошибок, вызванных влиянием одних фрагментов кода на другие — регрессии.

Командная работа также подразумевает использование нетривиальных приемов программирования — шаблонов проектирования. С их помощью код разбивается на необходимые структурные элементы, которые документируются и тестируются независимо друг от друга. Если все программисты, работающие над одним проектом, будут говорить на одном «языке» архитектуры приложения, каждый сможет писать такие независимые модули. Вероятность их «поломки» будет стремиться к нулю. Паттерны проектирования, модульные тесты, документация кода — это своего рода письменное соглашение между программистами о том, как они работают над конкретным проектом.

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

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

1. Переменные, функции, методы, пакеты, модули используют буквы в верхнем регистре, слова используют более низкое ударение между ними: например. check_pass или _socket.

2. Классы и исключения используют заглавные буквы в начале и верхний регистр между словами вместо пробела, например, CamelCase или JustCounter.

3. Защищенные методы и внутренние функции используют знак ударения перед словами: _start_engine

4. Приватные методы используют перед собой два знака подчеркивания: __foo(self, …).

5. Константы пишутся в верхнем регистре: IP_SERVER=’111.11.11.11’.

6. Лучше использовать обратную запись:

элементы = …

active_elements = …

defunct_elements = …

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

Импорт PEP8

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

Порядок группировки импорта:

1. Встроенные пакеты Python.

2. Сторонние пакеты.

3. Локальные пакеты.

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

Длина линии PEP8

Существует множество устройств, в которых длина строки ограничена 80 символами; также, ограничив ширину окна до 80 символов, мы можем разместить несколько окон рядом друг с другом. Автоматический перенос строк на такие устройства нарушит форматирование, и код будет труднее понять. Поэтому ограничьте длину до 79 символов.

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

even_numbers = [var вместо var в диапазоне (400)

если переменная % 4 == 0]

Пространства PEP8

Лучший способ сделать отступ — использовать пробелы. Они должны производиться только с использованием табуляции. Код, содержащий табуляции и пробелы, следует исправить. При вызове интерпретатора в командной строке с параметром -t он выдаст предупреждение, если вы используете смешанный стиль в отступах. При запуске интерпретатора командной строки -tt вы получите ошибки в этих местах.

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

1. Ставим пробел между двоеточием и значением ключа в словаре:

names = {‘gagan’: 456}

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

вар = 40

math_operation_result = 40 * 5

3. Не ставить пробел между операторами при передаче в качестве параметра:

деф count_even(num=27):

пройти

4. Ставим пробел после запятой:

переменная1, переменная2 = get_values(число1, число2)

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

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

Python воспринимает символ control+L (или ^L) как пробел. Многие редакторы рассматривают его как разрыв страницы, поэтому его можно использовать для выделения логических частей файла на разных страницах. Обратите внимание, что не все редакторы распознают Ctrl+L и могут отображать вместо него другой символ.

Документация PEP8

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

Многострочная документация должна состоять из:

  • Строки с кратким описанием.
  • Пример использования, если есть.
  • Аргументы.
  • Тип возвращаемого значения и семантика, если None не возвращается.

Пример:

Автомобиль класса:

"""Простое изображение автомобиля.

:param brand: строка, марка автомобиля.

:param model: строка, модель автомобиля.

“””

def __init__(я, торговая марка, модель):

self.brand = бренд

self.model = модель

Вывод

Стоит ли тратить время на «красивый» дизайн кода в соответствии с различными руководствами по стилю Python? Или это плохие мысли, которые приходят от безделья, а главное, что код работает?

Начнем с самого главного: если код не работает, вам не нужно тратить время на оценку других его параметров. Если код не работает, это отсутствующий код.

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

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

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