одной из причин, по которой наше общество может функционировать, является наша способность общаться в стандарте? правильно сформированный и универсальный%, хотя и с местными + культурными вариациями% понятный путь) это требует согласования не только символов, но и их использования? неявно или явно? как передатчиком + получателем информации)) если бы такая однородность присутствовала? Можно ли написать так, как ему нравится, и если разные люди по-разному истолковывают документы? мы бы жили в хаотичном состоянии общения + наши коллективные интеллектуальные достижения ~~ невозможно =
Этот абзац трудно понять, потому что некоторые знаки препинания были изменены и изменены соглашения о форматировании: использование знака плюс для обозначения сочетания «и», вопросительного знака вместо запятой и двойных закрывающих скобок, где можно ожидать точку. Если бы использовались наши принятые правила написания, параграф выглядел бы так:
Одной из причин, по которой наше общество может функционировать, является наша способность общаться стандартным, хорошо сформированным и универсальным — хотя и с местными и культурными вариациями — понятным способом. Это требует, чтобы не только символы, но и их использование были согласованы, неявно или явно, как передатчиком, так и получателем информации.
Если бы такого единообразия не было, если бы можно было писать так, как ему нравится, и если документы по-разному интерпретировались разными людьми, мы бы жили в хаотичном состоянии общения, и наши коллективные интеллектуальные достижения были бы невозможны.
Потребность в стандартах в области технических коммуникаций, включая символы на чертежах, давно осознана, и Международная организация по стандартизации (ИСО) и ее братья во всех промышленно развитых странах существуют для удовлетворения этой потребности. В искусстве все не так требовательно, но есть некоторые правила, называемые стилями. Архитекторы и поэты часто связаны с кучей из них. Авторы прозы и художники имеют гораздо больше свободы, но все еще подчиняются некоторым правилам.
Автором кода, таким как вы и я, является автор кода, разработчик программного обеспечения. В нашей торговле вещи не всегда понятны. Как и медицина, компьютерное программирование — это отчасти наука, отчасти техника и отчасти искусство. Мы должны соблюдать некоторые правила, чтобы глупые машины, для которых мы пишем, могли понять наши желания. Но в остальном мы можем писать, что хотим, так, как хотим.
Или мы?
Все очень хорошо и хорошо следовать собственным правилам частного программирования (например, с использованием имен переменных camelCase) при индивидуальной написании изолированных приложений, таких как небольшой бюджетный веб-сайт. Однако совместная работа требует согласования общих правил, или вы знаете, что происходит, и, если по какой-то случайности вы этого не сделаете, я предлагаю вам взглянуть на рассказ, который я рассказал в моей статье « Непрерывная интеграция» (с Дженкинсом) .
Тем не менее, если CI может вылечить болезни, типичные для групповой разработки, он бессилен иметь дело с потенциальными проблемами в интеграции различных приложений, где совершенно разные стили могут затруднить понимание «исходного» кода (за исключением, может быть, первоначального разработчика) или даже привести к столкновению имен. Чтобы удовлетворить эту потребность, группа разработчиков предложила стандарт для использования с PHP, известный как PSR-X, как описано в статьях PSR-1 и PSR-2 Хари К, для утверждения в качестве стандартов .
Хотя еще рано гарантировать, что PSR будут широко приняты в качестве стандарта де-факто для написания серьезных приложений PHP, интересно отметить, что анализатор и исправитель кода, который ищет отклонения кода, был разработан не менее чем Фабьеном Потенциером, создатель фреймворка Symfony. (Et bien, ils ne sont pas fous, ces français!) В оставшейся части статьи мы узнаем, что делает его PHP-CS-Fixer и как его можно интегрировать с инструментом CI, таким как Jenkins.
Установка Fixer и основное использование
По словам его автора, инструмент исправления стандартов кодирования PHP для PSR-1 и PSR-2 «исправляет большинство проблем в вашем коде, когда вы хотите следовать стандартам кодирования PHP, определенным в документах PSR-1 и PSR-2». не решает все проблемы; и он не претендует на то, чтобы найти все отклонения от стандартов, но, снова цитируя Фабьена, он «поставляется с довольно большим количеством встроенных фиксаторов и искателей, но каждый с радостью предоставит больше из них».
Установка Fixer проста, а точнее, вообще отсутствует. Все, что вам нужно сделать, это загрузить последнюю версию php-cs-fixer.pharэтого сайта Sensiolabs (компания, которая стоит за Symfony). Поскольку средство исправления удобно упаковано в архив PHAR, все, что вам нужно сделать, это поместить его в удобную папку, например, в корневой каталог вашего сервера разработки, и запустить его из командной строки:
jajeronymo @ desktop: ~ / www $ php php-cs-fixer.phar fix / path / to / dir
Это будет искать и исправлять проблемы PSR во всех файлах в каталоге (папке) в конце /path/to/dir Если вы хотите проверить / исправить только один файл, вместо этого используйте путь к файлу:
jajeronymo @ desktop: ~ / www $ php php-cs-fixer.phar fix / path / to / file
Чтобы проверить исправление, я написал скрипт «Hello World» с тремя преднамеренными нарушениями PSR: открывающий тег без обозначения «php». вкладка, используемая для отступа вместо четырех пробелов, и закрывающий тег в сценарии только для PHP:
<?
echo "Hello World";
?>
Файл был сохранен в той же папке, что и fixer-test.php Затем я побежал:
jajeronymo @ desktop: ~ / www $ php php-cs-fixer.phar fix fixer-test.php
Единственный ответ, который я получил на терминале, был:
1) /home/prospero/www/fixer-test.php
Однако я проверил свойства fixer-test.php Открыв сценарий, я заметил, что исправитель добавил обозначение ‘php’ после открывающего тега, заменил тег отступа двумя пробелами (о, я ожидал четыре!) И не удалил закрывающий тег, а добавил перевод строки после него — что соответствует требованию стандарта о том, что файл всегда должен заканчиваться пустым переводом строки. Из любопытства я запустил фиксатор второй раз и обнаружил, что закрывающий тег был удален.
На данный момент мы успешно установили PHP-CS-Fixer для работы, но только в базовом режиме. Сценарий имеет достаточное количество параметров, которые могут быть изучены пользователем. См. Раздел использования веб-страницы приложения для получения более подробной информации.
Дженкинс, будешь следить за этим для меня, пожалуйста?
Как объяснялось в моих статьях, упомянутых во вступительной части этой статьи, Jenkins — это инструмент для автоматизации ряда задач, включая тестирование, необходимых для непрерывной интеграции. Если у вас нет Jenkins, обратитесь к разделу «Настройка Jenkins» в Continuous Integration (с Jenkins), часть 2 . Установите и запустите Jenkins и вернитесь сюда.
Запустите файл войны Дженкинса и укажите в браузере http://localhost:8080 Нажмите «Создать новые рабочие места», а затем выберите «Создать проект программного обеспечения в свободном стиле». Дайте работе имя. (С тех пор как я изучал программирование на мэйнфрейме Берроуза, я называю свои тестовые задания «Троттер». Интересно, может ли кто-нибудь из моих читателей догадаться, почему.)
Установите флажок «Построить периодически» и напишите «* / 5 * * * *» в поле расписания, чтобы запускать тест каждые пять минут. Теперь есть два пути, которыми мы можем следовать. Чтобы запустить только PHP-CS-Fixer, нам нужно выполнить команду оболочки (или, в Windows, командный файл), и Jenkins будет действовать как суррогат элемента управления заданиями cron. Для интеграции с более сложным набором тестов и задач можно добавить в него скрипт Ant.
Чтобы следовать первому варианту, выберите «Выполнить оболочку» в раскрывающемся меню «Добавить этап сборки» в разделе «Сборка». В текстовом поле поместите команду для запуска фиксатора, указав абсолютный путь к файлам или папкам. Для моего тестового сценария это:
php /home/jajeronymo/www/php-cs-fixer.phar fix /home/jajeronymo/www/fixer-test.php
Сохраните конфигурацию. До остановки или выключения Jenkins будет запускать программу исправления для файла fixer-test.php Чтобы увидеть исправление в действии, создайте некоторые отклонения в тестовом файле, например, подавив ‘php’ из открывающего тега, и подождите, пока Jenkins не запустит исправитель. Затем откройте тестовый файл, чтобы проверить сделанные исправления.
Если никаких изменений не происходит или если в списке сборок на панели инструментов Jenkins отображаются красные шары, происходит ошибка. Нажмите на время задания, чтобы открыть его запись, а затем на ссылку «Вывод на консоль», чтобы узнать, что происходит, а что нет.
Наконец, чтобы запустить исправление из скрипта Ant, добавьте его к существующему содержимому:
<project name="user">
...
<exec executable="php" failonerror="true">
<arg line="/home/prospero/www/php-cs-fixer.phar fix /home/prospero/www/fixer-test.php" />
</exec>
...
</project>
Резюме
Принятие стандартов кодирования необходимо для снижения затрат на разработку сложных веб-приложений, а также для гарантии того, что инвестиции будут постоянными и не будут зависеть от первоначальной команды разработчиков. Предложение PSR может быть способом к этому, и его простота использования с платформами CI, такими как Jenkins, стала возможной благодаря таким инструментам, как PHP-CS-Fixer.
Изображение через Fotolia