Python: Линтер
Теперь, когда мы уже научились писать простые программы, можно немного поговорить о том, как их писать.
Код нужно оформлять определенным образом, чтобы он был достаточно понятным и простым в поддержке. Специальные наборы правил — стандарты — описывают различные аспекты написания кода. Конкретно в Python стандарт один — PEP8. Он отвечает практически на все вопросы о том, как оформлять ту или иную часть кода.
В любом языке программирования существуют специальные инструменты — так называемые линтеры. Они проверяют код на соответствие стандартам. В Python их достаточно много, и наиболее популярный из них — flake8.
Взгляните на пример:
Линтер будет «ругаться» на нарушение правила: E225 missing whitespace around operator. По стандарту, оператор + всегда должен отделяться пробелами от операндов.
E225 — лишь одно из большого количества правил. Другие правила описывают отступы, названия создаваемых сущностей, скобки, математические операции, длину строчек и множество иных аспектов. Каждое отдельное правило кажется довольно мелким, не очень важным. Но вместе они составляют основу хорошего кода. Список всех правил flake8 доступен тут.
Сайт сейчас не будет проверять ваш код линтером, но в ваших будущих практиках на Хекслете (и в реальной разработке) линтер будет работать и сообщать вам о нарушениях.
Задание
Выведите на экран результат следующего вычисления: «разница между пятью в квадрате и произведением трёх и семи». Напишите код так, чтобы каждый оператор отделялся от операндов пробелами.
Линтеры в Python
В сообществе Python, как и в любой другой группе людей, существует некое коллективное знание. Множество людей прошлось по всем возможным граблям и получило опыт через набитые шишки. Затем через какое-то время, благодаря выступлениям на конференциях, официальным заявлениям, документам, статьям в блогах, код-ревью и личному общению, это знание стало коллективным. Теперь мы просто называем его “хорошими практиками”.
К таким хорошим практикам можно отнести, например, следующие.
Соблюдать (и даже просто помнить) все хорошие практики — не самая простая задача. Зачастую люди плохо справляются с тем, чтобы отсчитывать пробелы и контролировать переменные, и вообще склонны допускать ошибки по невнимательности. Таковы люди, ничего не поделаешь. Машины, наоборот, прекрасно справляются с такими хорошо определёнными задачами, поэтому появились инструменты, которые контролируют следование хорошим практикам.
В компилируемых языках ещё на этапе компиляции программист может получить по щщам первый полезный фидбэк о написанном коде. Компилятор проверит, что код валиден и может быть скомпилирован, а также может выдать предупреждения и рекомендации, как сделать код лучше или читаемее. Т.к. Python является интерпретируемым языком, где этап компиляции как таковой отсутствует, линтеры особенно полезны. На самом деле, это очень важно и круто — узнать, что твой код как минимум является валидным Python-кодом, даже не запуская его.
В этом посте я рассмотрю два самых популярных линтера для Python:
Термин “lint” впервые начал использоваться в таком значении в 1979 году. Так называлась программа для статического анализа кода на C, которая предупреждала об использовании непортабельных на другие архитектуры языковых конструкций. С тех пор “линтерами” называют любые статические анализаторы кода, которые помогают находить распространённые ошибки, делать его однообразным и более читаемым. А названо оно «lint» в честь вот такой штуки:
flake8
Установка
Чистое зло Python
Темные силы не дремлют. Они пробираются в дивное королевство Python и используют черную магию, чтобы осквернить главную реликвию — чистый код. Однако опасны не только злые чары.
Сегодня я расскажу о страшных чудовищах, которые, возможно, уже обжились в вашем коде и готовы устанавливать свои правила. Здесь нужен герой, который защитит безмятежный мир от злобных тварей. И именно вы станете тем, кто сразится с ними!
Все готово, выступаем в поход!
Пожиратели пространства
А вот и первые проблемы. Жители стали замечать, как нечто лакомится пробелами, а операторы обретают причудливые формы:
Настала пора обнажить меч и принять бой:
Враг повержен, и сразу вернулись прежние чистота и ясность!
Загадочные точки
Теперь жители сообщают о появлении странных глифов. О, смотрите-ка, вот и они!
Ага, теперь понятно. Действительно, эти точки — краткая запись значений типа float (в первом случае) и Ellipsis (во втором). И в обоих случаях происходит обращение к методу, также через точку. Давайте посмотрим, что же скрывалось за этими знаками:
На этот раз все обошлось, но впредь не сравнивайте константы друг с другом, дабы не накликать беду.
Кривая дорожка
А между тем у нас новая напасть — значения из некоторых веток в функции никогда не возвращаются. Давайте разберемся, в чем дело.
Функция не возвращает значение ‘from_try’ из-за закравшейся в код ошибки. «Как ее исправить?» — изумленно спросите вы.
Мрачный СИ-луэт прошлого
Древнее существо пробуждается. Уже несколько десятилетий никто не видел его, но теперь оно вернулось.
Что тут происходит? Известно, что в циклах можно распаковывать разные значения: почти любые валидные в Python выражения.
Правда, многое из этого примера нам не следовало бы делать:
Метки Темного Колдуна
Насколько сложным может быть выражение на Python? Наверняка такие конструкции — происки злых сил. Это Темный Колдун оставляет свои замысловатые метки во всех классах, к которым прикасается:
Что же за ними скрывается? Похоже, у каждой метки свое значение:
Теперь, когда мы удалили или зарефакторили это выражение (со значением 19 по метрике сложности Jones Complexity), от метки Темного Колдуна в бедном классе не осталось и следа. Очередные ростки зла уничтожены.
Метамагия
Однако теперь наши классы связались с какими-то дурными типами, и те оказывают на них пагубное влияние.
Сейчас классы выдают очень странные результаты:
Давайте убедимся, что наш линтер-клинок по-прежнему остр:
Со всем разобрались, теперь наши классы в безопасности. Можем двигаться дальше.
Иллюзии
Иногда на пути встречаются выражения такие похожие, но такие разные. Вот и мы столкнулись с таким примером в коде. Выглядит, как самое обычное выражение-генератор, но на самом деле это кое-что совсем другое.
А вот и отчет об инциденте:
И давайте перепишем обработку, как нам предлагают.
Эта задачка была сложна, но и мы не лыком шиты. Что же дальше?
Злобный двойник email
Если нужно записать адрес электронной почты, то используем строку, ведь так? А вот и нет!
Для решения обычных задач существуют необычные способы. А у обычных типов данных есть злые двойники. Сейчас мы выясним, кто есть кто.
Разберемся, как это работает.
Этот пример значительно отличается от остальных тем, что он-то на самом деле корректный. Просто вот такой необычный. Вероятно, пользоваться им мы не будем, но в бестиарий запишем.
Сила заблуждений
В нашем королевстве настали смутные времена. Тьма наделила жителей сомнительными способностями. Это раскололо содружество разработчиков и привело к серьезным разногласиям.
Способности эти воистину страшные, ибо теперь вам дано программировать в строках:
Что происходит в этом примере?
Стоит ли использовать f-строки? Как хотите.
Стоит ли определять переменные в f-строках? Ни в коем случае.
Всего лишь импортируем модуль внутри строки, ничего такого, идем дальше.
Заключение
Мы сразились со многими жуткими монстрами, расплодившимися в коде, и сделали королевство Python прекраснее. Вы герой, гордитесь собой!
Это было невероятное приключение. И я надеюсь, что вы узнали что-то новое для себя, что поможет в грядущих сражениях. Мир нуждается в вас!
На сегодня все. Удачи на тракте, пусть звезды ярко освещают ваш путь!
Полезные ссылки
А вы, вольные жители Python королевства, встречались с подобной черной магией в вашем коде? Удалось ли справиться с ней? Или битва еще не завершена (или вовсе проиграна)? Если вам нужна помощь бывалых магов и чародеев Python, то приходите к нам на Moscow Python Conf++ 27 марта 2020 года. У нас будут проверенные рецепты по борьбе с плохим и старым кодом от Владимира Филонова (доклад + 2 часа практики), Кирилла Борисова и Левона Авакяна.
E225 should not require whitespace surrounding higher-precedence operators #166
Comments
eZanmoto commented Feb 14, 2013
At the moment, pep8 will signal an error for all of the following (defined in PEP8 as examples that should be allowed):
This behaviour conflicts with the following convention preceding these lines in PEP8:
If operators with different priorities are used, consider adding whitespace around the
operators with the lowest priority(ies). Use your own judgement; however, never use more
than one space, and always have the same amount of whitespace on both sides of a
binary operator.
If coding this rule is too complex for immediate implementation, I would suggest loosening the rule for the time being, so that the rule simply makes sure that there are is at most 1 space between operators and their operands.
The text was updated successfully, but these errors were encountered:
florentx commented Feb 15, 2013
This is a duplicate of issue #96, released with version 1.4
eZanmoto commented Feb 23, 2013
If operators with different priorities are used, consider adding whitespace around the
operators with the lowest priority(ies). Use your own judgement; however, never use more
than one space, and always have the same amount of whitespace on both sides of a
binary operator.
This should also mean that all operators inside parentheses may omit whitespace. I currently have an issue where the following statement is signalling E225 (missing whitespace around operator):
I believe that this format for the expression should be allowed, as I have omitted the spacing for the higher precedence expression (that inside parentheses), and including the spacing for the lower precedence expression.
florentx commented Feb 23, 2013
The whitespace is still mandatory (emitting E225 ) around:
The reason for this choice is that all these operators bind less tightly than the arithmetic operators (except the modulo % ).
The logic for the modulo % is that it is commonly used for string substitutions, and in this use case it makes sense to require spaces around it for readability.
IMHO in this example the parenthesis is enough to signal that the operation binds more tightly:
I agree that the PEP-8 specification give even more freedom regarding the whitespace around these non-arithmetic operators, however the current logic of the pep8 tool is defensible.
I re-open the issue in case someone else wants to comment on this request.
A possible solution might be to introduce again a new error code E227 which might be configured per project.
Чистое зло Python
Темные силы не дремлют. Они пробираются в дивное королевство Python и используют черную магию, чтобы осквернить главную реликвию — чистый код. Однако опасны не только злые чары.
Сегодня я расскажу о страшных чудовищах, которые, возможно, уже обжились в вашем коде и готовы устанавливать свои правила. Здесь нужен герой, который защитит безмятежный мир от злобных тварей. И именно вы станете тем, кто сразится с ними!
Все готово, выступаем в поход!
Пожиратели пространства
А вот и первые проблемы. Жители стали замечать, как нечто лакомится пробелами, а операторы обретают причудливые формы:
Настала пора обнажить меч и принять бой:
Враг повержен, и сразу вернулись прежние чистота и ясность!
Загадочные точки
Теперь жители сообщают о появлении странных глифов. О, смотрите-ка, вот и они!
Ага, теперь понятно. Действительно, эти точки — краткая запись значений типа float (в первом случае) и Ellipsis (во втором). И в обоих случаях происходит обращение к методу, также через точку. Давайте посмотрим, что же скрывалось за этими знаками:
На этот раз все обошлось, но впредь не сравнивайте константы друг с другом, дабы не накликать беду.
Кривая дорожка
А между тем у нас новая напасть — значения из некоторых веток в функции никогда не возвращаются. Давайте разберемся, в чем дело.
Функция не возвращает значение ‘from_try’ из-за закравшейся в код ошибки. «Как ее исправить?» — изумленно спросите вы.
Мрачный СИ-луэт прошлого
Древнее существо пробуждается. Уже несколько десятилетий никто не видел его, но теперь оно вернулось.
Что тут происходит? Известно, что в циклах можно распаковывать разные значения: почти любые валидные в Python выражения.
Правда, многое из этого примера нам не следовало бы делать:
Метки Темного Колдуна
Насколько сложным может быть выражение на Python? Наверняка такие конструкции — происки злых сил. Это Темный Колдун оставляет свои замысловатые метки во всех классах, к которым прикасается:
Что же за ними скрывается? Похоже, у каждой метки свое значение:
Теперь, когда мы удалили или зарефакторили это выражение (со значением 19 по метрике сложности Jones Complexity), от метки Темного Колдуна в бедном классе не осталось и следа. Очередные ростки зла уничтожены.
Метамагия
Однако теперь наши классы связались с какими-то дурными типами, и те оказывают на них пагубное влияние.
Сейчас классы выдают очень странные результаты:
Давайте убедимся, что наш линтер-клинок по-прежнему остр:
Со всем разобрались, теперь наши классы в безопасности. Можем двигаться дальше.
Иллюзии
Иногда на пути встречаются выражения такие похожие, но такие разные. Вот и мы столкнулись с таким примером в коде. Выглядит, как самое обычное выражение-генератор, но на самом деле это кое-что совсем другое.
А вот и отчет об инциденте:
И давайте перепишем обработку, как нам предлагают.
Эта задачка была сложна, но и мы не лыком шиты. Что же дальше?
Злобный двойник email
Если нужно записать адрес электронной почты, то используем строку, ведь так? А вот и нет!
Для решения обычных задач существуют необычные способы. А у обычных типов данных есть злые двойники. Сейчас мы выясним, кто есть кто.
Разберемся, как это работает.
Этот пример значительно отличается от остальных тем, что он-то на самом деле корректный. Просто вот такой необычный. Вероятно, пользоваться им мы не будем, но в бестиарий запишем.
Сила заблуждений
В нашем королевстве настали смутные времена. Тьма наделила жителей сомнительными способностями. Это раскололо содружество разработчиков и привело к серьезным разногласиям.
Способности эти воистину страшные, ибо теперь вам дано программировать в строках:
Что происходит в этом примере?
Стоит ли использовать f-строки? Как хотите.
Стоит ли определять переменные в f-строках? Ни в коем случае.
Всего лишь импортируем модуль внутри строки, ничего такого, идем дальше.
Заключение
Мы сразились со многими жуткими монстрами, расплодившимися в коде, и сделали королевство Python прекраснее. Вы герой, гордитесь собой!
Это было невероятное приключение. И я надеюсь, что вы узнали что-то новое для себя, что поможет в грядущих сражениях. Мир нуждается в вас!
На сегодня все. Удачи на тракте, пусть звезды ярко освещают ваш путь!
Полезные ссылки
А вы, вольные жители Python королевства, встречались с подобной черной магией в вашем коде? Удалось ли справиться с ней? Или битва еще не завершена (или вовсе проиграна)? Если вам нужна помощь бывалых магов и чародеев Python, то приходите к нам на Moscow Python Conf++ 27 марта 2020 года. У нас будут проверенные рецепты по борьбе с плохим и старым кодом от Владимира Филонова (доклад + 2 часа практики), Кирилла Борисова и Левона Авакяна.
