Если вы заядлый разработчик PHP, вполне вероятно, что вы столкнулись с сокращением PSR , которое означает «Рекомендация по стандартам PHP». На момент написания этой статьи их было четыре: от PSR-0 до PSR-3. Давайте посмотрим, что это такое, и почему вы должны заботиться (и участвовать).
Краткая история
У PHP никогда по-настоящему не было единого стандарта для написания кода. Те, кто поддерживает различные кодовые базы, уделяют время написанию собственных соглашений об именах и руководств по стилю кодирования. Некоторые из этих разработчиков предпочитают наследовать хорошо документированный стандарт, такой как PEAR или Zend Framework ; третьи предпочитают писать стандарты с нуля.
Framework Interoperability Group
Не стесняйтесь, чтобы открыть новую тему в списке рассылки .
На конференции php | tek в 2009 году люди, представляющие различные проекты, обсуждали свои варианты работы между проектами. Несомненно, неудивительно, что основным пунктом повестки дня было соблюдение набора стандартов между кодовыми базами.
До недавнего времени они называли себя «Группа стандартов PHP», но теперь они работают под эгидой Framework Interoperability Group (FIG). Как они чувствовали, первый не точно описал намерения группы. Несмотря на то, что название этой группы явно относится к фреймворкам, разработчики, представляющие все виды проектов, были приняты в качестве членов с правом голоса .
FIG намеревается разместить сечение экосистемы PHP, а не только разработчиков фреймворков. Например, каждый из фреймворков Symfony, Lithium и CakePHP имеет представителя в качестве члена с правом голоса, но то же самое касается PyroCMS, phpDocumentor и даже Composer.
Участвующие в голосовании участники могут участвовать в голосовании или участвовать в нем, однако любой желающий (включая вас!) Может стать участником сообщества PHP-FIG, подписавшись на список рассылки PHP-FIG .
В этом списке рассылки проходят обсуждения, голосования, предложения и отзывы.
Цель
Целью ФПГ является создание диалога между представителями проекта с целью поиска путей совместной работы (совместимость). На момент написания этого диалога появилось четыре Рекомендации по стандартам PHP: от PSR-0 до PSR-3.
Эти рекомендации бесплатны и могут быть приняты любым, хотя никто не обязан это делать. Фактически, голосующие участники не обязаны реализовывать какие-либо PSR в проектах, которые они представляют!
PSR-0 : стандарт автозагрузчика
PSR-0 — огромный шаг вперед для многоразового кода.
Помните, как вы использовали для указания многих операторов require ссылки на все необходимые вам классы? К счастью, этот шаблон изменился с помощью магической функции __autoload() PHP 5. PHP 5.1.2 сделал автозагрузку еще лучше, введя spl_autoload() , которая позволяет регистрировать цепочку функций автозагрузки с помощью spl_autoload_register() .
Независимо от того, насколько хороша функция автозагрузки, она не определяет, как реализовать ее с помощью существующих кодовых баз. Например, библиотека X может подходить к структуре каталога и имени класса не так, как библиотека Y , но вы можете использовать оба!
Написание правильного автозагрузчика, который знает, где искать все возможные полностью определенные имена, а также проверять все расширения файлов (.class.php, inc.php, .php и т. Д.), Быстро превратится в беспорядок. Без стандарта, определяющего, как называть классы и где их размещать, совместимость автозагрузчика все равно была бы несбыточной мечтой.
Встречайте PSR-0 . Стандартная рекомендация, которая описывает «обязательные требования, которые необходимо соблюдать для обеспечения совместимости автозагрузчика».
PSR-0 — огромный шаг вперед для многоразового кода. Если проект соответствует стандарту PSR-0 и его компоненты слабо связаны, вы можете просто взять эти компоненты, поместить их в каталог vendor и использовать совместимый с PSR-0 автозагрузчик для включения этих компонентов. Или, что еще лучше, пусть Composer сделает это за вас !
Например, это именно то, что делает Laravel с двумя компонентами Symfony (Console и HttpFoundation).
На фиг.2 приведен пример реализации совместимой с PSR-0 функции автозагрузчика, которая может быть зарегистрирована в spl_autoload_register() , но вы можете использовать любую из более гибких реализаций, такую как разъединенный Symfony ClassLoader или автозагрузчик Composer .
PSR-1 : базовый стандарт кодирования
PSR-1 фокусируется на базовом стандарте кодирования.
После принятия PSR-0 на ФИГ имелось длительное время низкой активности. На самом деле прошло полтора года, прежде чем документы PSR-1 и PSR-2 были утверждены.
PSR-1 фокусируется на базовом стандарте кодирования. Он воздерживается от излишней детализации и делает это, ограничивая себя набором основных правил, чтобы «обеспечить высокий уровень технической совместимости между общим кодом PHP».
- Используйте только теги
<?phpи<?=. - Используйте только код UTF-8 без спецификации для кода PHP.
- Отдельные побочные эффекты (создание выходных данных, доступ к базе данных и т. Д.) И объявлений.
- Применять PSR-0.
- Имена классов должны быть определены в StudlyCaps.
- Константы класса должны быть определены в верхнем регистре с разделителями подчеркивания.
- Имена методов должны быть определены в camelCase.
Основные правила сосредоточены на соглашениях об именах и структуре файлов. Это гарантирует, что весь общий код PHP ведет себя и выглядит одинаково на высоком уровне. Представьте себе приложение, которое использует множество сторонних компонентов, и все они используют разные соглашения об именах и кодировки символов. Это было бы беспорядок!
PSR-2 : Руководство по стилю кодирования
Цель PSR-2 состоит в том, чтобы иметь единое руководство по стилю для кода PHP, которое приводит к равномерному форматированию общего кода.
PSR-2 расширяет и расширяет базовые стандарты кодирования PSR-1. Его целью является создание единого руководства по стилю для PHP-кода, которое приводит к равномерно отформатированному общему коду.
Правила руководства по стилю кодирования были определены после обширного опроса, проведенного среди членов ФИГ, участвующих в голосовании.
Правила в PSR-2, согласованные участниками голосования, не обязательно отражают предпочтения каждого разработчика PHP. Однако с самого начала ФИГ PHP-ФИГ заявил, что их рекомендации всегда были для самой ФИЖ; другие, желающие принять рекомендации, являются положительным результатом.
Полная спецификация PSR-2 может быть найдена в репозитории fig-standard . Обязательно прочитайте.
В идеальном мире каждый проект PHP будет принимать рекомендации, содержащиеся в PSR-1 и PSR-2. Однако из-за вкуса (то есть «Соглашение об именах x выглядит лучше, чем y!», «Вкладки через пробелы!») И исторической сегментации между различными стилями кодирования, было лишь небольшое количество PHP-проектов, принимающих PSR-1 и PSR-. 2 во всей полноте.
PSR-3 : интерфейс логгера
PSR-3 описывает общий интерфейс ведения журнала.
Стандартная рекомендация PHP № 3 является самым последним дополнением к принятым стандартам FIG. Он был принят 27 декабря 2012 года с впечатляющим количеством голосов от 18 до 0 (8 голосовавших не проголосовали).
PSR-3 описывает общий интерфейс ведения журнала, включающий восемь уровней системного журнала протокола Syslog (RFC 5424) : отладка, информация, уведомление, предупреждение, ошибка, критическое состояние, предупреждение и аварийная ситуация.
Эти восемь уровней Syslog определены как имена методов, которые принимают два параметра: строку с log $message и необязательный массив $context с дополнительными данными, которые не вписываются в первую строку. Реализаторы могут затем заменить заполнители в $message значениями из $context .
Стандарт общего интерфейса, такой как PSR-3, приводит к тому, что фреймворки, библиотеки и другие приложения могут вводить подсказки в этот общий интерфейс, что позволяет разработчикам выбирать предпочтительную реализацию.
Другими словами: если известно, что компонент ведения журнала соответствует PSR-3, его можно просто заменить другим компонентом ведения журнала, совместимым с PSR-3. Это обеспечивает максимальную совместимость между вызовами реализаций регистратора.
Монолог недавно внедрил PSR-3. Поэтому известно, что он реализует Psr\Log\LoggerInterface и связанные с ним руководящие принципы, приведенные в документе PSR-3 .
критика
PHP-FIG делает большую работу по централизации стандартов PHP.
Некоторые люди говорят, что PSR зашли слишком далеко, чтобы определить глобальный набор стандартов для определения стиля кодирования, что является скорее субъективным, чем объективным. Другие считают, что общий интерфейс слишком специфичен и не гибкий. Но критика приходит естественно с любой стандартной инициативой. Людям не нравится, как должны называться идентификаторы, какой отступ используется или как формируются стандарты.
Большая часть критики и размышлений происходит со стороны, после того, как стандарты приняты, даже несмотря на то, что стандарты формируются в списке рассылки (который открыт для всех, чтобы присоединиться и оставить отзывы, комментарии или предложения). Не стесняйтесь открывать новую тему в списке рассылки , если вы считаете, что хотите добавить что-то ценное.
Также важно помнить, что это не конкретная комбинация правил, которые способствуют выгоде рекомендуемых стандартов, а скорее наличие единого набора правил, которые совместно используются различными кодовыми базами.
Каждый, кто уклоняется от своих собственных предпочтений, у нас есть один непротиворечивый стиль извне, что означает, что я могу использовать ЛЮБОЙ пакет — не только то, что происходит в CamelCase.
— Фил Осетрин в списке рассылки PHP-FIG
Будущее
FIG намеревается разместить сечение экосистемы PHP, а не только разработчиков фреймворков.
С ростом числа влиятельных участников голосования и четырьмя принятыми стандартами FIG, безусловно, набирает обороты в сообществе PHP. PSR-0 уже широко используется, и, надеюсь, PSR-1 и PSR-2 последуют его примеру, чтобы добиться большей однородности в общем PHP-коде.
С общим интерфейсом, определенным в PSR-3, Framework Interoperability Group сделала новый поворот в рекомендации стандартов. Они по-прежнему движутся в этом направлении, так как содержимое новых общих интерфейсов обсуждается в списке рассылки.
В настоящее время идет интересное обсуждение предложения пакета сообщений HTTP , который содержит общие интерфейсы для реализации клиента HTTP. Есть также различные обсуждения, предлагающие общий интерфейс Cache; но, на данный момент, кажется, что на низкой активности.
Независимо от того, каковы будут результаты этих предложений, PHP-FIG отлично справляется с задачей централизации стандартов PHP. Они, без сомнения, оказывают положительное влияние на экосферу PHP, и, надеюсь, их усилия получат более заметное место в языке программирования PHP.
Помните: в настоящее время они по-прежнему работают под названием Framework Interoperability Group и не намерены говорить вам — программисту Джо — о том, как создавать ваши приложения. Они просто рекомендуют набор стандартов, который может принять каждый.