Есть много способов убедиться, что ваш код соответствует заданному стандарту кода — мы рассмотрели несколько ранее. Но внедрить стандартную команду и убедиться, что все знают об ошибках до того, как они будут применены к проекту, не так-то просто сделать. Travis и Jenkins могут быть настроены на выполнение этих проверок, но они не так просты в этом, как решение, которое мы собираемся рассмотреть: Nitpick CI .
Nitpick CI — это простой простой инструмент, позволяющий одним щелчком мыши убедиться, что отправленные запросы Github соответствуют стандарту PSR-2. К сожалению, в настоящее время Nitpick работает только с этими двумя конкретными (но популярными) векторами — только Github и только PSR-2. Это бесплатно для проектов с открытым исходным кодом, так что давайте попробуем.
Бутстрапирование
Чтобы протестировать Nitpick, мы создадим новый репозиторий на основе thephpleague / skeleton и представим, что создаем новый пакет PHP. Скелет уже уважает PSR-2, поэтому он является идеальным кандидатом для недействительного пиара. Не стесняйтесь следовать!
git clone https://github.com/thephpleague/skeleton nitpick-test cd nitpick-test find . -type f -print0 | xargs -0 sed -i find . -type f -print0 | xargs -0 sed -i 's/:author_usernamename/swader/g' find . -type f -print0 | xargs -0 sed -i 's/:author_website/http:\/\/bitfalls.com/g' find . -type f -print0 | xargs -0 sed -i 's/:author_email/[email protected]/g' find . -type f -print0 | xargs -0 sed -i 's/:vendor/sitepoint/g' find . -type f -print0 | xargs -0 sed -i 's/:package_name/nitpick-test/g' find . -type f -print0 | xargs -0 sed -i 's/:package_description/nitpick-test package for a SitePoint tutorial/g' rm CONDUCT.md rm -rf .git Приведенные выше команды клонируют скелет, заменяют значения заполнителей на реальные значения и удаляют некоторые файлы, которые нам не нужны. Теперь проект готов к тому, чтобы его зафиксировать и отправить в онлайн (если вы создали репозиторий на Github).
git init git remote add origin YOUR_ORIGIN git add -A git commit -am "Initial commit" git push -u origin master
Теперь мы можем сказать Nitpick, чтобы отслеживать это.
Конфигурирование Nitpick
Чтобы настроить Nitpick, нам нужно всего лишь зарегистрироваться для этого через Oauth Github:
Получив разрешение на просмотр репо аккаунта, Nitpick предложит список с одной кнопкой «Активировать» рядом с каждым.
Есть даже удобное поле поиска для мгновенной фильтрации списка репо, если у вас есть сотни. Один клик по кнопке «Активировать», и это все, что нужно. Nitpick сейчас просматривает проект на наличие PR и автоматически сканирует их. Давайте попробуем!
PR без кода
Во-первых, давайте проверим это на PR без кода и посмотрим, как отреагирует Nitpick. Мы удалили файл CONDUCT на первых этапах этого урока, но нам не удалось удалить ссылку на него из файла README. В верхней части файла README также есть «примечание», которое необходимо удалить.
Мы можем внести эти изменения в онлайн-интерфейс, нажав кнопку редактирования в файле README:
Чтобы создать проверяемый PR, мы просим Github создать новую ветку и новый запрос на извлечение:
Как и ожидалось, пиар остался нетронутым — на самом деле ничего не происходит, и мы можем слить его. В файле нет кода для проверки, поэтому уведомления не выдаются.
Запрос на получение действительного кода
Теперь давайте добавим изменение в пример контроллера. Изменение должно быть минимальным, просто чтобы посмотреть, будет ли Nitpick что-нибудь делать. Для простоты мы можем снова использовать веб-интерфейс.
Мы можем изменить содержимое src/SkeletonClass.php на:
< ?php namespace League\Skeleton; class SkeletonClass { /** * Create a new Skeleton Instance */ public function __construct() { // constructor body } /** * Friendly welcome * * @param string $phrase Phrase to return * * @return string Returns the phrase passed in */ public function echoPhrase($phrase) { $phrase .= "- and here is a suffix!!"; return $phrase; } }
И опять ничего не происходит. Nitpick даже работает?
Неверный запрос на извлечение кода
Теперь давайте напишем некоторый код PSR-2 специально. PSR-2 заявляет:
НЕ ДОЛЖНО быть жесткого ограничения на длину линии; мягкий предел ДОЛЖЕН быть 120 символов; строки ДОЛЖНЫ быть 80 символами или меньше.
и
Видимость ДОЛЖНА быть объявлена для всех свойств и методов; абстрактный и окончательный ДОЛЖНЫ быть объявлены до видимости; статический ДОЛЖЕН быть объявлен после видимости.
Хотя есть еще много правил , их, кажется, достаточно легко нарушить. Давайте изменим содержимое src/SkeletonClass.php на:
<?php namespace League\Skeleton; class SkeletonClass { $someProp = "foo"; public $someOtherProp = "bar"; /** * Create a new Skeleton Instance */ public function __construct() { // constructor body } public final function thisIsNotPsr2() { echo "Hello!"; } /** * Friendly welcome * * @param string $phrase Phrase to return * * @return string Returns the phrase passed in */ public function echoPhrase($phrase) { $phrase .= "- and here is a suffix!! But it doesn't end there - we have here a very, very long line that's actually a bunch of text. Technically, it should be broken up or something I guess."; return $phrase; } }
Мы добавили два свойства, из которых только одно определено в соответствии с правилами. Другой отсутствует декларация видимости. Кроме того, мы добавили технически допустимый, но недействительный по стандартам метод, который определяет его окончательность после видимости, а затем весь текст в той же строке, что и объявление метода. Наконец, мы расширили ранее добавленный суффикс до предельной длины.
После того, как мы представим PR, мы увидим, что все немного по-другому:
Nitpick показывает встроенные ошибки, в частности, указывая на то, что не так — будь то одно нарушение или несколько, как в случае с нашим добавленным методом.
Из-за того, что Nitpick комментирует PR напрямую, как если бы это делал пользователь, уведомления также отправляются по электронной почте, поэтому пропустить их практически невозможно:
Однако он упустил длину строки. Это не реагировало на это вообще. Это связано с тем, что Nitpick использует PHP CodeSniffer и его предустановку PSR-2, и то, с чем PHPCS считает действительным, согласен Nitpick. Что касается конкретной длины строки, PHPCS считает это просто предупреждением, которое мы можем увидеть, если запустить его вручную в нашем коде:
composer global require squizlabs/php_codesniffer ~/.config/composer/vendor/bin/phpcs --standard=PSR2 src/SkeletonClass.php
После проверки Nitpick не будет блокировать попытку слияния. Мы все еще можем пойти дальше и слить PR как обычно. Тем не менее, сообщения об инспекциях остаются на всеобщее обозрение, пока мы их не исправим. Давайте сделаем это сейчас. В командной строке мы клонируем ветку этого пиара:
git fetch origin git checkout -b Swader-patch-3 origin/Swader-patch-3
Затем мы вносим необходимые изменения, изменяя содержимое SkeletonClass.php на:
<?php namespace League\Skeleton; class SkeletonClass { public $someProp = "foo"; public $someOtherProp = "bar"; /** * Create a new Skeleton Instance */ public function __construct() { // constructor body } final public function thisIsNotPsr2() { echo "Hello!"; } /** * Friendly welcome * * @param string $phrase Phrase to return * * @return string Returns the phrase passed in */ public function echoPhrase($phrase) { $phrase .= "- and here is a suffix!! But it doesn't end there - we have here a very, very long line that's actually a bunch of text. Technically, it should be broken up or something I guess."; return $phrase; } }
После совершения и нажатия с:
git add -A git commit -m "Fixed nitpicks" git push origin Swader-patch-3
… Единственное, что мы получаем об исправлении ошибок, это тот факт, что предыдущие комментарии Nitpick к пиару устарели:
Наш пиар теперь готов к объединению!
Вывод
Хотя Nitpick, по общему признанию, очень специфичен в своем случае использования, он также очень хорош в этом — он делает одно, и делает это хорошо. Для его настройки достаточно одного щелчка, и вся команда получает выгоду от расширенных стандартных проверок, которые теперь могут быть исключены из других инструментов CI, таких как Jenkins и Travis, вместо этого они могут сосредоточиться на реальных тестах. Будучи бесплатным для открытого исходного кода и невероятно простым в настройке, нет никаких причин не попробовать.
Конечно, есть несколько щупалец с Nitpick:
- из-за того, что Nitpick использует PHPCS изнутри, мы ограничены возможностями инструмента. Мало того, мы также ограничены интерпретацией правил PSR-2. Там нет никакого способа настроить набор правил или определить другую реализацию стандарта (на данный момент).
- когда появляются ошибки, в пиаре нет индикатора блокировки. Инструменты CI, такие как Travis и Scrutinizer, делают это очень хорошо, поскольку они работают вместе и используют индикатор готовности PR, чтобы пометить сбой или неудачу сборки. Хотя стандарты кода не оказывают реального влияния на прохождение или провал технической реализации сборки, было бы неплохо получить более визуальную обратную связь в духе этих инструментов.
- когда ошибки исправлены, нет четкого указания на исправленные проблемы. Мне нравится подход Scrutinizer — четкие указания в пиаре и электронное письмо, в котором говорится, что некоторые проблемы были исправлены. Это отправляется всей команде, так что все сразу на той же странице.
Тем не менее, я обязательно активирую Nitpick на всех моих проектах с открытым исходным кодом — просто нет причин не делать этого. Как опытный пользователь PSR-2, я могу оставить проверку стандартов на Nitpick и забыть обо всем этом в таких инструментах, как Travis и Scrutinizer, вместо этого позволяя этим инструментам сосредоточиться на важных вопросах — проверке кода и тестах.
Что вы используете для проверки кода? Вы полагаетесь на внешние инструменты или только локальные инструменты? Возможно оба? Дайте нам знать!