Что такое линтер?

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

Что же такое линтер?

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

Первый линтер был написан Стивеном Джонсоном в 1978 году, когда он работал с операционной системой Unix в Bell Labs. После этого появилось много других линтеров для разных целей и языков, не только C.

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

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

Эволюция линтеров

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

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

Статический анализ

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

Если ты разработчик Python, возможно, ты уже знаком с Radon. Он может подсчитывать строки исходного кода (SLOC), строки комментариев, пустую строку и другие необработанные метрики, но также может вычислять «Индекс читабельности», который может быть очень важным в некоторых проектах.

Это просто пример. Существует множество других линтеров, которые выполняют проверки статического анализа.

Стандартизация кода

Стандартизация кода - отличный способ вывести разговор на более продуктивный уровень. Наличие руководства и запуск линтеров для базы кода позволяет избежать эстетических изменений в твоем pull-request, таких как замена всех табуляций на пробелы, отступ при назначении переменной или даже перенос строк после заданного количества символов.

Такие стандарты переносят твое обсуждение на более важные темы, такие как архитектурные решения, проблемы безопасности или потенциальные ошибки.

Кстати, проблем с безопасностью и потенциальных ошибок также можно избежать с помощью линтеров!

Проблемы с безопасностью

Если ты увлекаешься Ruby on Rails, ты, вероятно, слышали о Brakeman. Это инструмент безопасности статического анализа. Полезно найти потенциальные проблемы с безопасностью. Например, он запускает проверки на предмет внедрения SQL-кода при использовании ActiveRecord #find_or_create_by. Он также добавляет проверки XSS, параметры конфигурации и многое другое.

Ruby - не единственный язык с таким движком. SourceLevel поддерживает множество движков для разных языков. Brakeman тоже в комплекте.

Возможные ошибки

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

Улучшения производительности

Каждый опытный разработчик знает не только важность выполнения программного обеспечения, но и множество приемов, которые его улучшают. Проблема в том, что насчет новичков? Как ты можешь передать эти знания? Даже опытные программисты могут пропустить пару приемов. Так почему бы не позволить программе автоматизации сделать это за тебя?

Знаешь ли ты, что универсальный селектор (*) в CSS может замедлить загрузку страницы? Или что неквалифицированные селекторы атрибутов имеют те же характеристики производительности, что и универсальный селектор? Лучше, всегда избегать их.

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

Другие аспекты

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

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

Преимущества линтинга

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

Повышает уровень обсуждения обзора кода

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

Делает код похожим на написанный одним человеком

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

Обеспечивает видимость состояния твоей кодовой базы

Чтобы узнать состояние твоего кода есть замечательный способ, это - добавить этап в конвейер CI / CD для измерения эволюции состояния работоспособности твоего кода. Более того, ты можешь принять меры как можно скорее, когда увидишь, что его состояние ухудшается.

Повышает осведомленность и ответственность за качество кода

Опытные разработчики могут изучить разницу и поднять соответствующие вопросы по предлагаемому изменению: являются ли имена переменных описательными? Сколько строк занимает метод? Есть ли суперкласс?

А как насчет новичков? Знания в команде часто неоднородны. Это означает, что не каждый разработчик знает, на что смотреть в коде. Наличие линтера, который автоматически распознает запах кода - отличный способ распространить эти знания и возложить ответственность за изменения на команду.

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

Контролирует технический долг

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

Явное указание возможных проблем в коде, в процессе его проверки, помогает разработчикам или инженерам программного обеспечения выявлять, обсуждать и исправлять их перед объединением в основную ветвь (перед мержем в мастер). Это очень удобная практика, позволяющая уберечь код от дурных практик.

Примеры линтеров

Линтеров существует огромное количество. В зависимости от языка программирования для каждого задания может быть даже несколько линтеров. Например, для языка программирования Go существуют ktlint и Detekt. Оба выполняют аналогичную работу. То же самое происходит с eslint, линтером, разработанным для JavaScript. Он работает очень похоже на tslint или jshint.

Линтеры для безопасности

• Brakeman для Ruby
• Bandit для Python
• Node Security для JavaScript

Линтеры по стилю и соглашению о кодировании

• CSSLint. SCSS Lint и Sass Lint для CSS
• Gofmt для Go language
• Swiftlint для Switft
• rustfmt для Rust
• Credo для Elixir

Линтеры для статического анализа

• pep8 для Python
• Phan или PHP Mess Detector для PHP
• kibit для Clojure, ClojureScript, cljx
• PMD для Java

Завершение

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

Мы называем это автоматизацией проверки кода. Каждый репозиторий может иметь свой файл конфигурации для линтера, а затем, перед пул реквестом делать проверки с указанными правилами стиля кода.

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

Источник: https://sourcelevel.io/blog/what-is-a-linter-and-why-your-team-should-use-it