Линтер кода - это инструмент статического анализа кода, используемый для отметки ошибок программирования, ошибок, стилистических ошибок и подозрительных конструкций. Термин происходит от утилиты Unix, которая исследовала исходный код языка C. Как и Google, lint стало глаголом, означающим статическую проверку исходного кода.

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

Линтинг - это важный процесс, и линтеры кода доступны для всех языков программирования. В этом блоге мы поговорим конкретно о Python Linter, также известном как Pylint. Pylint проверяет ваш код на соответствие нормам, указанным в руководстве по стилю для Python, как указано в PEP-8.

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

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

И последнее, но не менее важное: коду присваивается общая оценка в зависимости от количества и серьезности предупреждений и ошибок.

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

1: Этот этап является наиболее близким ко всем основам и формирует первый уровень защиты вашего кода от фильтра качества. Pycharm остается неоспоримым и непобедимым чемпионом среди всех редакторов Python. Интеграция Pylint с Pycharm упрощает проверку на ворсинок одним нажатием кнопки.

По мере того, как вы продолжаете строить свой код, вы должны привыкнуть к непрерывному способу выполнения проверок. Для этого давайте воспользуемся функцией Внешний инструмент редактора. Шаги по интеграции Pylint в редактор красиво описаны в одном из ответов на переполнение стека.

Вы можете настроить pylint для работы с PyCharm, выполнив следующие шаги:

Установите pylint:

$ pip install pylint

Найдите папку с установкой pylint:

$ which pylint # MacOS/Linux
/usr/local/bin/pylint # this is just a possible output check yours
$ where pylint # Windows %LocalAppData%\Programs\Python\Python36–32\Scripts\pylint.exe # possible location

Откройте окно настроек PyCharm с помощью Файл - ›Настройки, затем перейдите к Инструменты -› Внешние инструменты на боковой панели. (Или выполните поиск «внешние инструменты»)

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

Чтобы запустить pylint из Tools -> External Tools -> pylint:

Посмотрите результат в терминале PyCharm:

2: вторые ворота обеспечивают 1-й уровень управления качеством кода. Этот шлюз не позволяет разработчику вносить какой-либо код (имеющий линты) в репозиторий GIT. В Git есть различные веб-хуки, которые упрощают разработку. Для линтера кода мы будем использовать ловушку pre-commit. Это простой скрипт, который запускается перед любым событием фиксации.

Хук pre-commit запускается первым, еще до того, как вы наберете сообщение фиксации. Он используется для проверки моментального снимка, который собирается быть зафиксированным, чтобы увидеть, не забыли ли вы что-то, чтобы убедиться, что тесты выполняются, или для проверки того, что вам нужно проверить в коде. Выход из этого хука с ненулевым значением прерывает фиксацию, хотя вы можете обойти это с помощью git commit --no-verify. Вы можете сделать такие вещи, как проверка стиля кода (запустить lint или что-то подобное), проверить завершающие пробелы (ловушка по умолчанию делает именно это) или проверить соответствующую документацию по новым методам.

Ник Фицджеральд поделился здесь примером ловушки предварительной фиксации для запуска Pylint. Я рекомендую немного изменить этот пример сценария, реализовав аргумент Python Parser, чтобы включить динамическую выборку значения от пользователя вместо жесткого кодирования его в коде. Например: вы можете установить ранг передачи по умолчанию для проверок pylint, позволяя пользователю передавать значение, которое переопределяет значения по умолчанию. Это также помогает выбрать файл pylintrc у пользователя, если это необходимо.

До сих пор мы видели шлюзы, которые помогают нам в реализации и управлении проверками линта, однако эти 2 шага полностью зависят от пользователя / разработчика, поскольку их исключительная ответственность ложится на реализацию фильтров качества.

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

3: Интеграция pylint check с конвейером CI / CD образует пуленепробиваемый щит от компромиссов качества. Запустите линтер в своем конвейере CI (настроенном на запуск по запросу на извлечение) и пропустите / завершите конвейер на основе результатов проверок lint, тем самым запретив последовательность вашего кода от нижних ветвей к верхним (функция - ›dev, dev - ›мастер и др.).

Для демонстрации я использую CodeFresh для оркестровки конвейера CI. В приведенном ниже примере я создаю пакет Python и публикую его в диспетчере артефактов JFROG. Этот конвейер запускается всякий раз, когда возникает запрос на вытягивание из ветки функции в ветку разработки, и результаты отправляются обратно в Git с помощью служебной ловушки, зарегистрированной между Codefresh и Git.

Следовательно, проверяющий может обратиться к автоматическим проверкам, прежде чем приступить к действиям, которые необходимо предпринять в отношении запроса на слияние. Вы также можете настроить запуск сборки конвейера CI при слиянии PR, это полностью зависит от вас!

Что такое Pylintrc?

Вы бы заметили, что я уже несколько раз упоминал «pylintrc». Это книга правил, о которой я упоминал в начале этого блога. Это файл конфигурации для pylint, в котором указаны различные проверки, которые необходимо выполнить / пропустить, отклонившись от стандартного PEP-8.

Например: PEP-8, утверждает, что максимальная длина строки должна быть ограничена 79 символами:

Ограничьте все строки до 79 символов. Для потоковых длинных блоков текста с меньшим количеством структурных ограничений (строк документации или комментариев) длина строки должна быть ограничена 72 символами.

Однако большинство команд / проектов считают это ненужным и согласны с ограничением длины строки до 100/120 символов. Это переопределение должно быть указано в файле pylintrc как:

[FORMAT]
max-line-length=100

Точно так же, если вы хотите пропустить проверку строк документации модуля вместе с приведенной выше спецификацией, pylintrc будет выглядеть так:

[FORMAT]
max-line-length=100
[MASTER]
disable=
    C0114, # missing-module-docstring

Вы можете сгенерировать rc-файл по умолчанию, используя флаг pylint --generate-rcfile, и при необходимости установить переопределения.

pylint --generate-rcfile > .pylintrc

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

Вызов Pylint с конкретным файлом pylintrc необходимо выполнить, как показано ниже:

pylint --rcfile <PATH_TO_RC_FILE> <PATH_TO_PY_MODULE/FILE>

Одна из моих любимых цитат о компьютерном программировании:

Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям.

- Мартин Фаулер, 2008.

Я надеюсь, что это сообщение в блоге помогло вам начать работу с линтерами кода. Я твердо убежден, что лучший способ улучшить свои навыки программирования - это прочитать комментарии редакторов, когда вы начинаете разработку, и попытаться исправить их на месте. Когда вы начнете следить за сообщениями pylint, вы также узнаете более эффективные способы реализации той же функциональности. Это определенно помогает!

Кодирование с лучшими стандартами и улучшенным качеством требует практики и терпения. Самая сложная задача - начать работу. Как только вы отойдете от берега и начнете плыть, верьте ветру, и он плавно унесет вас в зенит.

Как я всегда считаю, начинайте с одного шага за другим!