Улучшаем качество кода с помощью автоматических утилит

    Достаточно большое число людей используют github для хранения исходного кода своих проектов. Идеология fork/pull request позволяет достаточно легко выполнять обзоры кода (code review). Обзоры кода в значительной степени позволяют поднять качество кодирования в проекте. Однако, часто человек выполняющий обзор кода вынужден заниматься проверкой стандартов кодирования принятых в проекте, и прочих очевидных вещей не связанных непосредственно с задачей решенной в pull запросе. Такие ошибки кодирования могут и должны быть обнаружены автоматически.

    lint(likely to be bugs) программы предназначены для нахождения подозрительных и непереносимых участков кода. Современные lint — программы, зачастую исследуют в том числе на соответствие стандарту кодирования. Конечно каждый разработчик обязан установить на свой компьютер утилиту для проверки кода и создавать pull запросы только если код чист. Однако, проблемы интеграции, неправильной настройки, не внимательность или просто халатность приводят к тому, что стандарты кодирования нарушаются. В сети существует достаточное число утилит выполняющих проверку кода, все они разношерстны в плане настроек и выходных форматов. В мультиязыковой компании это приводит к тому, что настройка рабочего места становится не тривиальной задачей.

    Предлагаю вашему вниманию сервис для автоматической проверки кода известными lint-утилитами. На данный момент поддерживаются:


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



    После продолжительных раздумий, вы получите сформированный отчет по всем файлам из pull запроса.



    Владельцы приватных репозиториев так же могут проверить свои pull запросы. Для этого нужно создать token доступа и вписать его в дополнительное поле формы. Если вас беспокоит здоровая форма паранои, то есть ещё возможность развернуть этот сервис у себя локально, кто заинтересовался прошу писать в личку.

    Другой вариант использования сервиса, воспользоватся плагинами к браузерам Сhrome или Firefox. После их установки в браузере появится кнопка, при нажатии на которую будет выполняться проверка открытого на текущей странице pull запроса.

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

    Например, хороший код:


    А этот не очень:


    Что бы настроить сервис на работу с вашим репозиторием, нужно создать WebHook URL unlint.org/github/hook:token. Параметр :token нужен только для приватных репозиториев, что бы обеспечить доступ проверяющего сервиса. Кто не очень знаком с github api может воспользоваться формой для генерации curl запроса на создания WebHook URL.

    ВАЖНО. Нельзя использовать форму в настройках вашего репозитория для создания WebHook URL потому, что она создает наблюдателя за вашими коммитами а не pull запросами, нужно использовать github api для создания WebHook URL наблюдающего за pull запросами.

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

    unlint.github.com
    Страничка проекта github

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

    Я нашел ошибку/Нужно добавить проверку
    Нужно написать мне, либо на github.

    Мне нужны другие стандарты
    Вы можете развернуть unlint локально и настроить любые проверки.

    Безопасно ли использовать token для доступа к приватному репозиторию?
    Нет, это не безопасно, т.к. данные передаются по незашифрованному каналу.

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

    Похожие публикации

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

      +1
      поддержку Ruby/Rails бы…

      для Rails существует Code Climate — интересный, удобный и няшный инструмент, помогающий рефакторить. Увы, приватные репы лишь за денежку.
        0
        Code Climate — это же по большей части удобная обертка для тех же гемов, что входят в состав metric_fu
          0
          Пытался найти линтер для Ruby, но что бы вот так просто взять и прикрутить не нашел.
          0
          AndroidLint не хватает
            0
            Спасибо за наводку, надо будет изучить после праздников. Сильно лучше чем java checkstyle?
              –1
              Разные вещи. AndroidLint предназначен чисто для анализа кода Android приложений.
            0
            Можно ли проверить не pull, а исходный репозиторий?
              0
              На данный момент нельзя.
              +3
              cpplint.py создан для проверки стиля кодирования компании Google. Этот стиль интересный, но какие-то вещи выглядят явными архаизмами. Например, запрет на использование шаблонов и исключений. Ну, а проверку копирайта в первой строке файла вообще приходится менять для каждой компании. Обычно этот скрипт качают и подгоняют на месте. Было бы интересно добавить в скрипт возможности подгонки стиля по какому-то множеству параметров. Иначе, по крайней мере, для C++, это малорименимо.
                +1
                В нашем проекте много шаблонов. cpplint не на один из них не выдавал предупреждения. Исключения тоже не были замечены в warning'ах. Кроме того, в рамках данного проекта cpplint запускается с некоторыми отключенными проверками (в том числе и проверка копирайта; полный список отключенных проверок может подсказать автор).
                Резюме: данный скрипт помог нам выявить достаточно много «вольностей», которые позволяют себе программисты при написании кода.
                  0
                  Да, конечно, некоторые проверки можно отключить опциями. Но, для полноценного использования я скрипт обычно подстраиваю. Какие типичные проблем сразу вспоминаются:
                  * Проблема с проверкой порядка включения заголовочных файлов. Проверяемый порядок включения таков: файлы стандартной библиотеки C, файлы STL, файлы третьих библиотек (в угловых скобках), файлы проекта (в двойных кавычках). Т.к. в Google не используют Boost, там ничего про него не сказано и программка ругается на такие заголовки. Скрипт приходится менять.
                  * Т.к. исключения в Google не разрешены, скрипт не знает ключевого слова catch и потому ругается на конструкцию вида catch (...). Скрипт думает, что это вызов функции, а в стиле Google между именами функций и скобками нельзя ставить пробелы. Надо добавить catch в список ключевых слов.
                  * Проверку копирайта конечно можно отключить, но хотелось бы ее как-то использовать. Я обычно в своих программах использую Doxygen комментарии и для описания файла задаю такой шаблон:
                  /** Copyright © 2011-2013, CompanyName.
                  * \file File name
                  * \brief File description.
                  * \author Author name.
                  * \date Date
                  */

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

                  В общем, было бы здорово иметь такие вещи в качестве параметров.
                +1
                А почему котенок по имени Гав? Типа «Давайте бояться нарушений стиля кодирования вместе»?
                  0
                  octocat с лапами :)
                  0
                  pep8 — это style guide, и одноименная тулза для чека.
                  А вот PyLint — это уже то что надо.
                    0
                    Просто не силен в питоне после праздников постараюсь прикрутить.
                    +1
                    OCLint бы еще прикрутить.
                    • НЛО прилетело и опубликовало эту надпись здесь
                        0
                        CI уже есть на базе jenkins.
                        • НЛО прилетело и опубликовало эту надпись здесь

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое