Стандарт pep 8 что это

Стайлгайд PEP8

PEP8 – это стайлгайд написания кода на Питоне. Он является частью Питона. Его все соблюдают.

Он отвечает на вопросы в таком духе,

• Табы или пробелы?
• Какая максимальная длина строки?
• Одинарные или двойные кавычки?
• Где ставить пробелы, а где — нет?
• Сколько ставить пустых строк?
• Как импортировать?
• Какой стиль именования сущностей?

Лучше прочитать оригинал документа PEP8 (если не осилишь – вот куцый перевод на русский). Особое внимание – к секции “A Foolish Consistency is the Hobgoblin of Little Minds”.

PEP 8 – закон. Его надо соблюдать. Если в вашей программе много нарушений PEP 8 – она выглядит неряшливо, по-дилетантски.

Помимо PEP 8 есть ещё pep8 . pep8 – это модуль, позволяющий проверять, соответствует ли код стандарту PEP 8. Сперва её надо установить ( pip install pep8 ), поле этого запустить, указав путь до файла или папки с кодом: pep8 ./2_wallie_how_are_you/wallie.py . Программа выдаст все нарушения PEP 8. Остаётся их только поправить.

Попробуйте бесплатные уроки по Python

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

Переходите на страницу учебных модулей «Девмана» и выбирайте тему.

PEP 8: что это такое и как применять

PEP 8, иногда обозначаемый PEP8 или PEP-8, представляет собой документ, содержащий рекомендации по написанию кода на Python. Он был составлен в 2001 году Гвидо ван Россумом, Барри Варшавой и Ником Когланом. Основная цель PEP 8 – улучшить читабельность и логичность кода на Python.

PEP расшифровывается как Python Enhancement Proposal («Предложение по усовершенствованию Python»), и их несколько. PEP — это документ для сообщества, который описывает новые функции, предлагаемые для Python, и содержит такие аспекты языка, как дизайн и стиль.

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

Из данной серии статей вы узнаете:

• как писать Python-код, соответствующий PEP8;
• какие доводы лежат в основе рекомендаций, изложенных в PEP8;
• как настроить среду разработки так, чтобы вы могли начать писать код на Python по PEP8.

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

“Читаемость имеет значение”, — Дзен Python

PEP 8 существует для улучшения читаемости кода Python. Но почему так важна удобочитаемость? Почему написание читаемого кода является одним из руководящих принципов языка Python?

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

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

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

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

Когда стоит игнорировать PEP 8

Краткий ответ на этот вопрос – никогда. Если вы строго следуете PEP 8, то можете гарантировать, что у вас будет чистый, профессиональный и читабельный код. Это принесет пользу вам, а также сотрудникам и потенциальным работодателям.

Однако некоторые рекомендации в PEP 8 неудобны в следующих случаях:

• соблюдение PEP 8 нарушает совместимость с существующим программным обеспечением
• код, связанный с тем, над чем вы работаете, несовместим с PEP 8
• код должен оставаться совместимым со старыми версиями Python

Как проверить соответствие кода PEP 8

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

Существует два класса инструментов, которые можно использовать для обеспечения соответствия PEP 8: линтеры и автоформаттеры.

Линтеры

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

Вот пара лучших линтеров для кода на Python:

pycodestyle

Это инструмент для проверки вашего кода на соответствие некоторым стилевым соглашениям в PEP8.

Установите pycodestyle с помощью pip:

$ pip install pycodestyle

Вы можете запустить pycodestyle из терминала, используя следующую команду:

$ pycodestyle code.py

code.py:1:17: E231 missing whitespace after ',' code.py:2:21: E231 missing whitespace after ',' code.py:6:19: E711 comparison to None should be 'if cond is None:'

flake8

Это инструмент, который сочетает в себе отладчик, pyflakes и pycodestyle.

Установите flake8 с помощью pip:

$ pip install flake8

Запустите flake8 из терминала, используя следующую команду:

$ flake8 code.py

code.py:1:17: E231 missing whitespace after ',' code.py:2:21: E231 missing whitespace after ',' code.py:3:17: E999 SyntaxError: invalid syntax code.py:6:19: E711 comparison to None should be 'if cond is None:'

Замечание: Дополнительная строка в выводе указывает на синтаксическую ошибку.

Автоформаттеры

Автоформаттеры – это программы, которые автоматически реорганизуют ваш код для соответствия PEP 8. Одна из таких программ — black . Она автоматически форматирует код для приведения его в соответствие с большинством правил PEP 8. Единственное, она ограничивает длину строки до 88 символов, а не до 79, как рекомендовано стандартом. Однако вы можете изменить это, добавив флаг командной строки, как в примере ниже.

Установите black с помощью pip. Для запуска требуется Python 3.6+:

$ pip install black

Его можно запустить из командной строки, как и в случае с линтерами. Допустим, вы начали со следующего кода, который не соответствует PEP 8, в файле с именем code.py:

for i in range(0,3): for j in range(0,3): if (i==2): print(i,j)

Затем вы можете запустить следующую команду через командную строку:

$ black code.py reformatted code.py All done! ✨ ? ✨

code.py будет автоматически приведён к следующему виду:

for i in range(0, 3): for j in range(0, 3): if i == 2: print(i, j)

Если вы хотите изменить ограничение длины строки, можно использовать флаг —line-length :

$ black --line-length=79 code.py reformatted code.py All done! ✨ ? ✨

Работа двух других автоформаттеров – autopep8 и yapf – аналогична работе black .

О том, как использовать эти инструменты, хорошо написано в статье Python Code Quality: Tools & Best Practices Александра ван Тол.

В следующих статьях цикла про PEP 8 читайте:

• Нейминг и размещение кода
• Комментарии, пробелы, выбор методов

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

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

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

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

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

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

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

Гвидо ван Россум

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

• выбор кодировки исходного кода;
• группировку инструкций по импорту модулей;
• максимальную длину строки кода — рекомендуется до 79 знаков, а для строк документации (docstring) — 72 знака;
• использование отступов — табуляции и пробелов;
• использование пустых строк для разбивки кода на блоки и выделения функций верхнего уровня;
• использование комментариев;
• именование переменных, констант, классов и экземпляров, функций, аргументов, модулей, пакетов;
• выбор уровня доступности классов и методов (public, private, API-подклассы), а также порядка их наследования.

Пишете ли вы код в PyCharm, Notepad++ или другом редакторе, сохранять .py-файлы лучше в кодировке UTF-8. Для Python 3 она рекомендована официально, для Python 2 формально требуется кодировка ASCII, но она не поддерживает кириллицу, поэтому для приложений на русском разумно использовать ту же UTF-8. Если по какой-то причине вам очень нужна «альтернативная» кодировка исходника, обязательно укажите её в комментарии в первой строке файла:

 # coding: cp1251 print("Текст в кодировке Windows 1251.") input() 

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

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

Самое известное требование PEP 8 по оформлению Python-кода — отступы . С их помощью задают структуру условий, циклов, функций. Традиционно на один уровень отступа ставят четыре пробела . Например:

if sunny: print("The sun is shining!") else: pass 

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

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

Интересный факт: исследование 2017 года на Stack Overflow показало, что программисты, которые делают отступы пробелами, зарабатывают почти на 9% больше, чем любители Tab’а.

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

1. Сразу после открывающей скобки и перед закрывающей: ( x ) — так не надо.
2. Перед скобками при вызове аргумента. Неправильно: arg (1). Правильно: arg(1).
3. Перед скобками индекса и среза: dict[‘step’] = map[i].
4. Между именем параметра/аргумента, знаком «=» и значением: min(a=10, b=input).

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

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

x = (y + 1) * (y — a)

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

act1() act2() act3()

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

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

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

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

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

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

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

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

 if  i_have_apples: # делаем то if not key_obtained: # делаем это

Если нужно сравнить что-то со значением «None», вместо операторов сравнения используйте is/is not .

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

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

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

try: something() except Exception as exc: raise AnotherDamnError(str(exc))

• Старайтесь минимизировать количество кода в конструкциях try… except. Это поможет избежать трудных в обнаружении ошибок.
• По возможности выбирайте синтаксис, который работает для всех реализаций Python: CPython, Jython, PyPy и других.

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

Пока вы создаете маленькие проекты, вычитывать код на ошибки и нарушения стиля не проблема. В работе над большими проектами выручат скрипты автоматической проверки кода . PyCharm проверяет написанное «на лету». А если нужно поработать без IDE? На GitHub есть целый раздел Python Code Quality Authority , где хранятся утилиты для повышения качества кода, в том числе для проверки стиля на соответствие PEP 8: flake8 , pycodestyle , pep8-naming . Когда будет нужно, вы сможете интегрировать Flake8 в свою среду разработки.

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

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

Если конкретный код при подгонке под стиль становится уродливым, «такой хоккей нам не нужен». Например, если разбивка на строки по 72 символа усложняет чтение, PEP 8 предлагает удлинить строку до 80 или даже 100 символов — в зависимости от того, что удобно вам и вашей команде разработки. Чёткие ограничения действуют только для публичных проектов-библиотек.
Дополнительное чтение: если вы вошли во вкус, добавьте в свой список ещё и статью « Пиши как настоящий Питонист: идиоматика Python» . Также советуем просмотреть вебинар о применении Python в реальном мире.

Сравнение стандарта PEP8 и «Чистого кода» Роберта Мартина

Привет, Хабр! Признаюсь, честно, за время моего отсутствия я успел по вам соскучиться.

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

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

Главный разработчик провёл ревью и пришёл к выводу, что мне пока рано занимать такую вакантную должность. Вместе с этим HR отправил рекомендации разработчика, как и в каком направлении можно развиваться. Одно из них – чтение книги «Чистый код» под авторством Роберта Мартина

Я сначала не придал особого значения этой книге. За время обучения программированию на Python мне много рекомендовали что почитать. Что-то мне нравилось, что-то нет. Но здесь всё решил один случай.

Через три дня после собеседования я поехал на крупнейшую IT конференцию на Урале DUMP2022. Там познакомился со многими практикующими разработчиками в том числе из этой компании. Какова была моя радость, когда на одной из секций докладчик отметил мой вопрос как лучший, а подарком как раз стала эта книга.

Я понял, что это был знак. Мне действительно надо было прочитать эту книгу. И как оказалось не зря.

Нет, эта статья не очередной обзор, на парадигму автора. Это статья о сравнении двух стандартов PEP8 и «Чистого кода». Вместе с вами я посмотрю чем отличаются эти два стандарта между собой, в чём их сходство. Полученные знания углубят понимание фундаментальных принципов программирования и возможно повлияют на стиль оформления кода.

О «Чистом коде»

Книга Роберта Мартина перевернула мои взгляды о программировании на 180 градусов. До прочтения книги я не задумывался о том, что надо грамотно именовать переменные, грамотно оформлять функции, классы, дизайнерить архитектуру приложения. Про написание юнит тестов вообще промолчу. Всегда считал, что знание юнит тестов больше нужны тестировщику, а не разработчику. Какой же я наивный!

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

Когда закончил чтение книги, то понял, что парадигма Чистого Кода является стандартом, к которому стремятся придерживаться крупные IT компании города Екатеринбург (напр. ТОЧКА или СКБ-КОНТУР). И притом совершенно не важно на каком языке я программирую.

Автор пишет код на языке Java. К слову сказать, я не нашёл в интернете какие-либо стандарты (вроде PEP8 в Python), которые могли бы подойти для написания качественного кода на той же Java. Поэтому с осторожностью говорю, что «Чистый код» уже является в какой-то степени набором требований, к которым начинающему разработчику стоит присмотреться. И даже не важно соглашается ли он в полной мере с позицией автора или нет. Тут важно смотреть на альтернативные взгляды о проектировании кода и решать для себя какой подход наиболее подходящий, чтобы читатель кода меня правильно понял.

О стандарте PEP8

Если парадигма Clean Code является стандартом для языка Java, то в Python главным документом, по которому пишется качественный код является PEP8.

За основу написания документа взяты рекомендации создателя языка Python Гвидо ван Россума и дополнения Паула Барри. Программы, написанные по PEP8 читаются в едином стиле и его способен понять каждый Python разработчик. Использование стандарта при разработке программы можно достичь согласованности и единство кода. Я согласен с мнением автора, что согласованность кода со стандартом очень важна. Ведь меня читают другие люди.

Методика сравнения стандартов.

В качестве основного метода сравнения я выделил несколько ключевых слов, встречающиеся в PEP8 и в Чистом коде. Таким образом получился список из 8 пунктов:

1. Переменные
2. Функции
3. Аргументы функции
4. Комментарии
5. Обработка ошибок
6. Юнит тесты
7. Классы
8. Модули и системы

Переменные

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

CLEAN CODE

1. Переменные описываются именем существительным
2. Для грамотного описания переменной разработчику следует задать самому себе следующие вопросы:

Для чего они используются?

Какую роль они выполняют?

Как они используются в дальнейшем?

1. Использование стандартной номенклатуры, там где это необходимо. Например, если мы используем декоратор
2. Использование однозначных имён

PEP8

1. Переменные отражают то, где они используются, а не что реализуют.
2. Стандарт предполагает использование переменных в разных стилях

Наиболее предпочтительные для стандарта стили:

1) Одиночная маленькая буква (например «i»)

2) Одиночная заглавная буква (например «A»)

3) Слово в нижнем регистре (например «apple»)

4) Слова из маленьких букв с подчёркиваниями (‘one_two_three’)

5) Заглавные букв (СapWords, CamelCase) (например: OneTwoThree)

6) Переменные с префиксами (например: _one)

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

Выводы по блоку «Переменные»

Исходя из полученной информации на мой взгляд кажется верным факт, что CleanCode дополняет формат PEP8. Однако тут существует различные взгляды на использование префиксов в именовании переменных. Автор Clean Code утверждает, что в качественном коде префиксы не используются. Однако в Python переменные не делятся на публичные и приватные. Чтобы отделить одного от другого для именования переменных используется знак «земля» (_) перед приватным именем.

Таким образом получается закономерный вывод, что если Python разработчик хочет использовать парадигму «Clean Code» то ему следует оставить знак «_» для определения приватных методов, а во всех остальных случаях лишние префиксы исключить. Именование переменных лучше использовать начиная со слова в нижнем регистре или CamelCase стиле

Функции

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

Примером реализации функции на языке Python является следующий код:

def function(arg1, arg2): newValue = arg1 + arg2 return newValue

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

CLEAN CODE

1. Функция описывается глагольной формой и служит для описания поведения переменных.
2. Автор рекомендует называть функцию так, чтобы она выполняла только одно действие. Эта рекомендация сопоставима с принципами SOLID.
3. Размер функции ограничивается 20 строками в ширину и 120 символами в длину
4. Не рекомендуется использовать дублирующий код.
5. Не рекомендуется возвращать пустые значения в операторе return.

PEP8

1. Рекомендуется использовать такой же стиль написания, как и при именовании переменных. Например, если мы называем переменные в стиле CamelCace, следовательно и функции мы называем в CamelCase.
2. Для отделения одной функции от другой рекомендуется использовать 4 пустых строки
3. Длина строки ограничивается максимум 79 знаками

Выводы по блоку «Функции».

По оформлению функций тоже видно, что сравниваемые стандарты сопоставимы и в какой-то степени дополняют друг друга. Различие описывается правилами оформления. То есть, если Мартин определяет длину кода 120 символами, то по PEP8 она ограничивается 79. Но тут мне понравилась рекомендация Мартина. Он говорит, что правильно написанная функция по оформлению сопоставима с форматом монитора на ПК. В идеале, конечно, чтобы написанный код не выходил за рамки монитора.

Аргументы функции.

Аргументы функции я немного затронул в предыдущем разделе. Здесь я немного расширю их понимание. По сути своей аргументы — это часть функции. Они являются исходными данными для их преобразования в другие данные. Ниже рассмотрим как аргументы понимает Clean Code и PEP8

CLEAN CODE

1. Чем меньше аргументов принимает функция, тем легче она читается.
2. Считается, что, если функция принимает три и более аргументов – это плохая функция.
3. . Не допускается использовать Null (None) в качестве аргумента функции.

PEP8

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

Выводы по блоку «Аргументы функции».

В целом разделы из CLEAN CODE и PEP8 также являются сопоставимыми. Примерно одинаковую по объёму информацию можно найти как в CLEAN CODE, так и в PEP8.

Комментарии

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

В языке Python комментариями является текст, который начинается либо с решётки (#), либо с тройных кавычек. Примеры комментариев представлены ниже.

#Комментарий def function(arg1, arg2): """ Это тоже комментарий :param arg1: :param arg2: :return: """ newNumber = arg1 + arg2 return newNumber

.Далее рассмотрим как видят комментарии авторы CLEAN CODE и PEP8.

CLEAN CODE

1. Любой комментарий в коде является предвестником того, что он написан плохо.
2. Они очень часто содержат неправдивую информацию, их достаточно сложно поддерживать и обновлять.
3. Они не отражают точное поведение функции
4. Если у программиста появляется мотивация писать комментарий, то это является первым признаком, что он пишет плохой код. Исключениями могут быть комментарии, содержащие авторское право и комментарии, начинающиеся с флагом #TO DO:

PEP8

1. Комментарии, противоречащие коду, хуже, чем отсутствие комментариев.
2. Комментарии должны являться законченными предложениями.
3. Старайтесь реже использовать подробные комментарии.

Выводы по блоку «Комментарии».

В Clean Code уделяется комментариям целая глава. Исходя из этого автор разбирает их более подробно, чем в PEP 8. Если Вы новичок в программировании, то вероятнее всего знать правила оформления комментариев по PEP8 будет достаточно. Но если выходить на реальные проекты, то вместе с PEP8 следует учитывать правила комментирования по Clean Code.

Обработка ошибок

Обработка ошибок описывается стандартным набором правил, которые предусматривают, что программист заранее знает, что программный код вернёт ошибку. Примером, описывающим применение этого инструмента служит блок try.

Далее представлю пример использования этого блока на языке Python. За основу я взял задачу из тренажёра CODE WARS Найти задачу можно тут. Кстати, вот пример того, как я её реализовал.

def find_function(func, arr): res = [] for value in func: try: if value.__name__ == '': for arr_value in arr: if value(arr_value): res.append(arr_value) except AttributeError: continue return res

Здесь применяется исключение для того, чтобы цикл смог без ошибки AttributeError завершить свою работу. Этот код был написан до прочтения Clean Code. Так что не судите слишком строго. Теперь рассмотрим что предлагают авторы CleanCode и PEP8.

CLEAN CODE

1. Очень желательно, чтобы ошибки не пришлось обрабатывать в коде.
2. Любое исключение нарушает логику работы интерпретатора.
3. Если не понять причины возникновение ошибок, то это в будущем приведёт к неработающему коду.
4. Обработка исключений является нарушением принципов SOLID
5. Если программист понимает, что вызова try не избежать то автор рекомендует придерживаться следующих правил:
   • Перед вызовом функции необходимо её проверить на ошибки.
   • Все ошибки обрабатывать с помощью блока ‘try’. Условные операторы типа “if-else” при обработке исключений лучше не использовать.
   • Применение «try» лучше всего подходит для тех случаев, когда нужно исключить ненужный код.
   • Использовать try необходимо в том коде, который обладает наибольшей уязвимостью.

PEP8

1. Стандарт налагает ограничение на использование блоков TRY в программировании. Использование исключений допускается только в двух случаях:
   • Если обработчик выводит пользователю всё о случившейся ошибке; по крайней мере, пользователь будет знать, что произошла ошибка.
   • Если нужно выполнить некоторый код после перехвата исключения, а потом вновь «бросить» его для обработки где-то в другом месте.
2. Авторы стандарта рекомендуют заключать в каждую конструкцию try. except минимум кода. Это необходим для того, чтобы легче отлавливать ошибки.

Выводы по блоку «Обработка ошибок».

Оба автора рекомендуют как можно меньше использовать инструмент по обработке ошибок и исключений в коде. Так же как и в предыдущем разделе в Clean Code автор рассматривает больше случаев, в котором допускается обработка ошибок. Поэтому вывод по данному разделу такой же как и по предыдущему. Если использовать Python для обучения языку, то стандарты PEP8 must have. Если вы претендуете на должность Junior разработчика, то знаний PEP8 будет уже недостаточно для прохождения собеседования. Желательно хотя бы знать базовые правила Clean Code.

ЮНИТ ТЕСТЫ

Я был слегка удивлён, когда при трудоустройстве на позицию Junior разработчика компания требует знать хотя бы основы работы Юнит Тестов. Всегда думал, что эта работа больше требуется тестировщикам, а не разработчиком. В данном разделе также следует знать, что разработка юнит-тестов не описывается стандартом PEP8.

По крайней мере мне такой информации найти не удалось. А вот, что пишет о них автор CLEAN CODE.

CLEAN CODE

1. Наличие юнит-тестов по степени важности находятся наравне с функциями, описывающими логику программного кода.
2. Тесты необходимы для того, чтобы разработчик программного обеспечения смог убедиться в том, что его код работает так, как он ожидает.
3. Написание грамотных тестов описываются правилами TDD (Test Driven Development) и состоит из трёх пунктов:
   • Пока нет юнит тестов, код нельзя допускать до массового потребителя
   • Тестов всегда мало. Поэтому чем больше юнит тестов, тем больше уверенности в корректности работы программы.
   • Если хотя бы один тест не удовлетворяет требованиям программы, то такую программу нельзя допускать до массового потребителя.
4. Юнит тесты должны быстро выполняться.
5. Предполагается, что они очень часто запускаются.
6. Они работают независимо друг от друга.
7. Они успешно запускаются на любой платформе и операционной системе.
8. Тесты выполняются без вмешательства их разработчика.

Выводы по блоку «Юнит Тесты».

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

Классы

Классы являются основой объектно-ориентированного программирования. Благодаря им мы можем разрабатывать сложные системы. В основу класса входят методы (они же описываются функцией). Примером класса, может являться например Корабль. Он обладает определённым набором функций, которые позволяют им управлять.

Далее я приведу пример класса на языке Python. Данный класс является решением Этой задачи. Это не идеальное решение. Уверен у вас будет лучше)

class Ship: def __init__(self, draft, crew): self.draft = draft self.crew = crew def is_worth_it(self): draft_crew = self.crew * 1.5 worth = self.draft - draft_crew return False if worth < 20 else True

Опишу как видят классы авторы CLEAN CODE и PEP8.

CLEAN CODE

1. Классы именуются именами существительными.
2. Чем длиннее название класса, тем меньше количество функций он в себе содержит.
3. Класс должен соответствовать принципам SOLID.
4. В классе содержится подробное описание его зоны ответственности.
5. Класс должен содержать малое количество переменных и функций.
6. Устройство класса:
   • Сначала объявляются публичные атрибуты класса.
   • Потом идут приватные атрибуты класса.
   • Затем идут публичные функции.
   • Далее приватные.

PEP8

1. Имена классов должны обычно следовать соглашению CapWords.
2. PEP8 предполагает использование self в качестве первого аргумента метода экземпляра объекта.
3. Чтобы избежать конфликтов имен с подклассами, используйте два ведущих подчеркивания (читайте префиксы).
4. Обязательно решите, каким должен быть метод класса или экземпляра класса (далее - атрибут) — публичный или непубличный.

Выводы по разделу "Классы"

В Python организация классов разрабатывается несколько иначе, чем на Java. Поэтому к применению Clean Code в Python разработке следует подходить с особой осторожностью. Например, если в языке Java надо явно определять тип класса (public, private, protected), то Python такой возможности не имеет. Поэтому применение префиксов внутри класса становится оправданным, хотя в Clean Code их использование явно не приветстывуется.

Системы

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

В стандарте PEP8 работа системы описывается стандартами работы модуля

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

CLEAN CODE

1. Необходимо разделять процесс проектирования системы от её эксплуатации.
2. К этим процессам надо подходить с разных позиций. Можно рассмотреть процесс проектирования на примере строительства отеля. Когда его строят, то в процесс задействуются совершенно разные механизмы. Эти механизмы описываются единым общим процессом «строительство». Когда люди начинают его эксплуатировать, то здесь уже нанимается персонал, который отвечает не за строительство, а за обслуживание. Иными словами, процесс строительства и обслуживания никак не связаны между собой, за исключением только разве что наличия общего объекта.
3. Программные продукты, которые не учитывают разделение имеют шанс иметь проблемы с выполнением тестов.
4. Без разделения программных систем нарушается принцип единственной ответственности.
5. Следует отделять идейный код от работающего кода.
6. С ростом кода становится сложнее поддерживать системы.

PEP8

1. Модули должны иметь короткие имена, состоящие из маленьких букв.
2. Можно использовать символы подчеркивания, если это улучшает читабельность.
3. Новые модули и пакеты должны быть написаны согласно стандарту PEP8, но если в какой-либо уже существующей библиотеке эти правила нарушаются, предпочтительнее писать в едином с ней стиле c с программой, нарушающей стандарты.

Выводы по блоку "Системы".

Разработку систем авторы стандартов видят с разных точек зрения. Если авторы Clean Code видят систему как совокупность объектов с устоявшимися связями, то по PEP8 аналогом такой системы является модуль. В данном разделе я тоже склоняюсь к мнению, что использовать CleanCode при проектировании системы надо с осторожностью. Главное не нарушать принципы PEP8.

Общие выводы

Данный сравнительный анализ описывает далеко не все аспекты программирования. Он весьма поверхностный. Однако полученные выводы помогут дать ответ на вопрос: что можно использовать из книги Clean Code для разработки на Python и что использовать с осторожностью. Данная статья представляет взгляд новичка на проблему проектирования. Я понимаю, что для многих даже профессионалов эта тема даётся нелегко. Поэтому буду рад замечаниям и дополнениям. Спасибо за внимание!

• Python
• Программирование
• Совершенный код
• Проектирование и рефакторинг