Стандарты кода в Python и популярные форматтеры?

МЕНЮ


Главная страница
Поиск
Регистрация на сайте
Помощь проекту
Архив новостей

ТЕМЫ


Новости ИИРазработка ИИВнедрение ИИРабота разума и сознаниеМодель мозгаРобототехника, БПЛАТрансгуманизмОбработка текстаТеория эволюцииДополненная реальностьЖелезоКиберугрозыНаучный мирИТ индустрияРазработка ПОТеория информацииМатематикаЦифровая экономика

Авторизация



RSS


RSS новости


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

— Конвенция PEP 8

python.org/dev/peps/pep-0008

Слово proposal чаще фигурирует в дискуссиях вокруг C++, чем в разговорах о Python — причина в несколько других принципах развития языка (и в том, что написать proposal к C++ может, в сущности, любой желающий). Однако и к обсуждаемому нами сегодня языку есть «предложения по улучшению» — дословно Python Enhancement Proposals, PEP.

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

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

Заучивать пункты PEP 8 необязательно — привести код в соответствие со стандартом и исправить ошибки помогут форматтеры.

— autopep8

pypi.org/project/autopep8

Про самый очевидный форматтер autopep8 мы подробно рассказывали в недавнем посте: vk.com/wall-84793390_13740 Добавим, что помимо стандартных функций причёсывания кода в autopep8 также есть параметр —aggressive, который убирает конечные пробелы и исправляет устаревшие фрагменты.

— autoflake

pypi.org/project/autoflake

Удаляет неиспользуемые переменные и импорт из кода, найденные с помощью pyflakes. По умолчанию форматтер чистит только стандартные модули библиотеки, но его настройки можно изменить с помощью параметра —imports. Также autoflake поможет удалить из кода лишние инструкции pass.

— unify

pypi.org/project/unify

Этот форматтер унифицирует написание кавычек в коде. Одним холиваром в большой команде меньше!

— docformatter

pypi.org/project/docformatter

Строки документации (docstrings) регулируются набором соглашений, описанных в PEP 257. Главное правило звучит так: «Всегда используйте тройные двойные кавычки вокруг строк документации» ("""triple double quotes"""). docformatter поможет автоматически расставить громоздкие конструкции из кавычек, а также соблюсти другие рекомендации.

— black

pypi.org/project/black

Наиболее строгий инструмент форматирования кода Python: все параметры регламентированы и ограничены. С одной стороны, это помогает придерживаться одного стиля, но с другой — некоторые правила могут показаться непривычными. Кроме того, black имеет всего две настраиваемые опции: изменение допустимой длины строки (по умолчанию — 88) и разрешение использования одинарных кавычек (по умолчанию — двойные).

Комментарии: