Области знаний
Партнёрские проектыМатериалы БРЭСпецпроектыСтать автором
Настроить видСменить языкИнформация
О РУВИКИ
Найти статью

PSR-стандарты

Pause

Экспертиза РАН

Logo-ran.pngLogo-ran-black.png
Проводится экспертиза
Российской академией наук
Подробнее
Times2.svg

Экспертиза РАН

Arrow-Right.png
Logo-ran.png
Проводится экспертиза
Российской академией наук
Подробнее

PSR-стандарты (PHP Standard Recommendation, «стандартная рекомендация PHP») — набор взаимосвязанных рекомендаций по стандартизации разработки на PHP, публикуемых группой совместимости фреймворков PHP-FIG (Framework Interop Group)[1]. Группа PHP-FIG объединяет крупные PHP-проекты, цель которых — обсуждение общего между проектами и поиск более эффективной совместной работы[2]. Рекомендации охватывают оформление кода, автозагрузку классов и стандартные интерфейсы компонентов: журналирование, кэширование, HTTP-сообщения, контейнеры внедрения зависимостей, обработку событий[3]. Каждая рекомендация имеет статус: принятая (accepted), черновик (draft), на рассмотрении (review), устаревшая (deprecated) или заброшенная (abandoned); черновик может измениться радикально, документ на рассмотрении — лишь незначительно[3]. Первые рекомендации — PSR-0 по автозагрузке и PSR-1/PSR-2 по стилю кодирования — признаны большинством сообщества PHP стандартом де-факто[4].

Общие сведения
Что важно знать
PSR-стандарты
Область использования разработка на PHP, стандартизация оформления кода, автозагрузка классов, совместимость библиотек
Дата появления 2010
Место появления США
Автор понятия PHP-FIG (Framework Interop Group)
Ключевые слова PHP-FIG, стандарт кодирования, автозагрузка, интерфейс компонента
Базовые понятия PHP, стандарт кодирования, интерфейс компонента, исходный код

История

Группа была организована разработчиками фреймворков на конференции php|tek в 2009 году; после подачи заявок и голосований размер группы вырос с первых пяти участников до более чем двадцати проектов[5]. После появления пространств имён в 2009 году в 2010 году была опубликована первая рекомендация PSR-0 по автозагрузке классов, задавшая общую структуру каталогов проектов и ставшая первым шагом к объединению фреймворков[6].

Состав группы с самого начала расширялся: после первых пяти проектов участники подавали заявки и проходили голосования, и со временем группа выросла до более чем двадцати проектов. Авторы ответов на частые вопросы подчёркивают, что PHP-FIG представляет срез сообщества и охват проектов будет расширяться[5]. Группа не имеет официального статуса от создателей языка: на упрёк в самоназначении представители отвечают, что в открытом сообществе назначающим органом выступает само сообщество[5].

В начале 2010-х годов набор рекомендаций расширился: помимо стиля кодирования (PSR-1, PSR-2) и автозагрузки появились интерфейсы общих компонентов — журналирования (PSR-3) и кэширования (PSR-6)[3]. В конце 2013 года PHP-FIG опубликовала рекомендацию PSR-4, решавшую ограничения PSR-0 и использованную по умолчанию в менеджере зависимостей Composer[6]. К концу десятилетия оформился современный стиль кодирования: в августе 2019 года был принят расширенный стандарт PSR-12, который развивает и заменяет PSR-2[7][8].

undefined

К началу 2020-х годов рекомендации фигурируют в профессиональной прессе как признанный базис: PSR-0 — PSR-4 признаны большинством сообщества в качестве стандарта де-факто. Однако, по оценке авторов обзора инструментов статического анализа, последующие попытки унифицировать более распространённые элементы приложений часто оказывались неудачными[4]. История группы сопровождалась уходом участников, включая авторов известных проектов Symfony, Laravel, Doctrine и Guzzle[4].

Группа PHP-FIG

PHP-FIG (Framework Interop Group) — группа состоявшихся PHP-проектов, обсуждающая общие черты между проектами и способы совместной работы; девиз группы — «двигаем PHP вперёд через сотрудничество и стандарты»[2]. Группа не является официальным органом языка: авторы ответов на частые вопросы подчёркивают, что решения принимает сообщество, а представительство проектов расширяется с течением времени[5]. PSR в этой системе — рекомендации, а не обязательные нормы: требования документов сформулированы ключевыми словами RFC 2119 («MUST», «SHOULD», «MAY»), различающими обязательные, рекомендуемые и возможные правила[9].

Работа над рекомендацией организована через роли и статусы. У каждого документа есть редакторы или ответственные за сопровождение; в индексе PHP-FIG для каждой рекомендации указаны номер, заголовок, сопровождающий и статус[3]. Пока рекомендация не отмечена как принятая, она может меняться: статус черновика допускает радикальные изменения, статус на рассмотрении — лишь незначительные[3]. Изменения проходят через голосования членов группы, а порядок работы закреплён уставом рабочего процесса PSR[3].

Индекс фиксирует и персональный вклад. PSR-3 и PSR-6 сопровождали Джорди Богджано и Ларри Гарфилд, PSR-7 — Мэтью Вейер О'Финни, PSR-11 — Матьё Наполи и Давид Негрие, PSR-12 — Корвин Сзанто. PSR-15 и PSR-17 — Вуди Гилк, PSR-16 — Пол Драгунис, PSR-18 — Тобиас Нюхольм, PSR-20 — Крис Сойферт[3]. Черновики PSR-5 и PSR-19 по документированию кода ведёт Чак Бёрджесс при поддержке Майкла Каллума, черновик интернационализации PSR-21 — Наварр Барнье и Ларри Гарфилд[3].

undefined

Рекомендации охватывают четыре направления: стиль кодирования, автозагрузка, интерфейсы компонентов и стандарты процессов[3]. Состав индекса по состоянию на октябрь 2026 года: 14 принятых, 4 черновика, 3 заброшенные и 2 устаревшие рекомендации — от PSR-0 до PSR-22[3].

Состав рекомендаций

Номер рекомендации закрепляется за документом навсегда, включая случаи, когда работа над ним прекращается: заброшенные номера PSR-8, PSR-9 и PSR-10 остаются в индексе со статусом «заброшенная»[3]. Устаревшие рекомендации не отменяются, а заменяются преемниками: PSR-0 устарел в пользу PSR-4, PSR-2 — в пользу PSR-12[3]. Ниже рассмотрены три основные группы документов.

undefined

Стиль кодирования

PSR-1 («базовый стандарт кодирования») закрепляет минимальные требования к файлам и именованию. Код должен использовать только теги `<?php` и `<?=`; файлы должны хранить код в UTF-8 без метки порядка байтов (BOM); файл должен либо объявлять символы — классы, функции, константы, — либо вызывать побочные эффекты, но не совмещать то и другое[9]. Имена классов объявляются в стиле StudlyCaps, константы классов — в верхнем регистре с разделителями-подчёркиваниями, имена методов — в стиле camelCase; соглашение об именовании должно применяться последовательно на уровне поставщика, пакета, класса или метода[9].

Требования к именам не существуют в отрыве от загрузки кода: PSR-1 связывает пространства имён и классы с рекомендациями автозагрузки, поэтому стилевые и загрузочные стандарты образуют единый каркас и применяются вместе[9]. Общие соглашения об именах в программировании при этом шире стиля языка: обзор практики собеседований отмечает, что до появления стандартов оформления часть разработчиков писала имена в верхнем регистре, часть — со смешанным регистром, а третьи — с разделителями-подчёркиваниями, и вечные споры о табуляциях и пробелах снижали читаемость кода разных авторов[6]. Требования именования стыкуются с общими соглашениями об именах в программировании и со стилями записи вроде snake_case[9].

PSR-2 развивал PSR-1 правилами оформления — отступами, длиной строк, положением скобок, — однако был признан устаревшим после принятия преемника[3]. Действующий стандарт PSR-12 («расширенный стиль кодирования») развивает и заменяет PSR-2, требует соблюдения PSR-1 и снижает когнитивную нагрузку при чтении кода разных авторов за счёт единого набора правил и ожиданий[8]. Профессиональная пресса отмечает, что заучивать все пункты оформления необязательно: существуют инструменты, автоматически проверяющие и форматирующие кодовую базу по стандартам PSR-2/PSR-12[6].

PSR-12 прямо называет цель — снизить когнитивную нагрузку при просмотре кода разных авторов — и достигает её перечислением общего набора правил и ожиданий оформления; документ требует соблюдения PSR-1 и охватывает то, что PSR-2 задавал для менее развитой версии языка[8]. Авторы обзоров подготовки к собеседованиям отмечают, что запоминать каждый пункт переноса скобки, пробела или отступа не требуется: соответствие стандарту проверяется автоматическими средствами, а разработчику достаточно понимать принципы[6].

undefined

Автозагрузка классов

Автозагрузка — механизм языка, подключающий файл класса в момент первого обращения без ручных включений; именно её стандартизация стала первой задачей группы[6]. PSR-0, опубликованный в 2010 году, описывал общий формат именования классов и структуру каталогов; с появлением опыта эксплуатации выявились ограничения формата, и в конце 2013 года группа опубликовала PSR-4[6]. PSR-0 сейчас имеет статус устаревшей рекомендации, PSR-4 — принятой[3].

PSR-4 описывает спецификацию автозагрузки классов из файловых путей[10]. Полное имя класса имеет форму `\<NamespaceName>(\<SubNamespaceNames>)*\<ClassName>` и обязано иметь пространство имён верхнего уровня — так называемое пространство поставщика; под-пространства допускаются в любом количестве; термин «класс» охватывает классы, интерфейсы, трейты и подобные структуры[10]. Рекомендация также описывает, где размещать файлы, автоматически загружаемые по спецификации[6].

Переход между поколениями автозагрузки задумывался мягким: PSR-4 может использоваться в дополнение к PSR-0, а также к любой другой спецификации автозагрузки, поэтому проекты переносили код по частям, не ломая установленные библиотеки[6]. Смена стандарта де-факто закрепилась с инфраструктурой менеджера зависимостей: новый стандарт работает по умолчанию в Composer, и отдельным разработчикам больше не требуется вникать в устройство автозагрузки под капотом[6]. На практике автозагрузку выполняет менеджер зависимостей Composer: PSR-4 используется в нём по умолчанию[6].

undefined

Интерфейсы компонентов

Вторая крупная группа рекомендаций — стандартные интерфейсы повторно используемых компонентов[3]. PSR-3 описывает общий интерфейс библиотек журналирования[11], PSR-6 — интерфейс кэширования, применяемый для повышения производительности проектов[12]. PSR-7 задаёт общие интерфейсы HTTP-сообщений. Спецификация опирается на RFC 7230 и RFC 7231, а также на RFC 3986[13]; PSR-15 развивает это направление интерфейсами серверных обработчиков запросов и промежуточных компонентов (middleware)[14]. PSR-17 описывает интерфейсы фабрик HTTP-объектов[15], а PSR-18 — интерфейс клиента для отправки HTTP-запросов и получения ответов[15].

Блок интерфейсов дополняют рекомендации для служебных подсистем: PSR-11 описывает общий интерфейс контейнеров внедрения зависимостей[16], PSR-14 закрепляет механизм событийной расширяемости приложений, позволяющий библиотекам и компонентам свободнее использоваться между проектами и поддерживающий практику событийно-ориентированной разработки[17]. К этой же группе относятся рекомендации простого кэша PSR-16, гипермедиа-ссылок PSR-13 и часов PSR-20[3].

Интерфейсный блок в материалах группы выделен в самостоятельное направление: на главной странице PHP-FIG примером совместной работы назван интерфейс журналировщика, а направлению HTTP посвящены сразу четыре принятые рекомендации — сообщения, обработчики, фабрики и клиент[2]. Столь плотный охват отражает структуру типового веб-приложения: запрос проходит через клиент и серверный обработчик, состояние ускоряется кэшем, события распределяются диспетчером, а зависимости доставляются контейнером[3]. Черновики продолжают работу над документацией кода: PSR-5 и PSR-19 развивают стандарт PHPDoc, а PSR-21 и PSR-22 — интернационализацию и трассировку приложений[3].

Отдельные документы не дошли до принятия: PSR-8, PSR-9 и PSR-10 заброшены, их номера останутся незанятыми навсегда; два из них касались процессов безопасности — уведомлений об уязвимостях и процедуры сообщения о них[3]. Заброшенные документы при этом фиксировали потребность сообщества в стандартизации процессов безопасности, и потребность осталась даже после закрытия работ[3].

Внедрение и инструменты

Внедрение PSR-стандартов опирается на инфраструктуру инструментов. Автозагрузку по PSR-4 выполняет Composer — менеджер зависимостей, использующий рекомендацию по умолчанию[6]. Стиль кода проверяется и форматируется автоматически: пресса отмечает возможности ручного форматирования в среде PhpStorm и продвинутый вариант — код-сниффер PHP CS Fixer, часто применяемый в непрерывной интеграции, чтобы не принимать коммиты с неотформатированным кодом[6].

Статические анализаторы дополняют проверку стиля проверкой корректности: в арсенале PHP-разработчика выделяют Easy Coding Standard (ECS), PHPStan и Psalm[4]. Выполнение статического анализа обычно является частью процесса непрерывной интеграции: анализатор читает исходный код без его запуска, позволяет ограничивать и предсказывать поведение программного обеспечения и упрощает проверку кода ревьюерами[4].

Пресса формулирует принцип внедрения как правило «что может быть автоматизировано, должно быть автоматизировано»: проверки соответствия стандартам выполняются при каждом пуше в основную ветку и при создании запросов на слияние, до человеческого ревью[4]. Разнообразие инструментов статического анализа в сообществе PHP при этом велико, и команды выбирают наборы проверок под проект, повышая предсказуемость поведения кода регламентами[4].

Российская норма безопасной разработки ГОСТ Р 56939-2016 также предусматривает статический анализ исходного кода как этап процесса[18].

undefined

Применение

Основная сфера применения PSR-стандартов — совместимость библиотек и фреймворков: единое именование классов и автозагрузка позволяют смешивать компоненты разных поставщиков в одном проекте, а стандартные интерфейсы — заменять реализации без переписывания потребителя[2][3]. Так, интерфейс журналирования PSR-3 используется библиотеками логирования, а приложения зависят от абстракции, а не от конкретного пакета[11].

Тот же принцип работает для HTTP-стека: приложения и библиотеки программируют против интерфейсов сообщений PSR-7, а конкретные реализации — серверные и клиентские пакеты — подменяются без изменения кода потребителя[13][15]. Снижение стоимости перехода между поставщиками — прямое следствие стандартизации интерфейсов: компонент, соответствующий рекомендации, работает с любым потребителем, ожидающим этот интерфейс[2]. PHP-фреймворки — Symfony, Laravel, Yii — входят в экосистему, для которой стандарты формулируются; журнал-обзор инструментов анализа называет авторов этих проектов среди участников сообщества[4].

Учебная и производственная практика разработки веб-приложений на PHP также опирается на стандартизированные структуры: обзоры разработки веб-приложений описывают типовую связку языка PHP, базы данных и веб-сервера, в которой фреймворки задают структуру приложения[19][20]. Методики обеспечения качества ПО относят к наиболее перспективным способам улучшения кода рефакторинг и тестирование[21], а проверка соответствия стандартам оформления — составная часть этих методик[6].

Сравнение с другими стандартами

PSR-стандарты дополняют международные стандарты качества программного обеспечения. Модель качества по ISO/IEC 9126 раскладывает качество ПО на характеристики — функциональность, надёжность, используемость, эффективность, сопровождаемость, мобильность, — и рекомендациям PSR в этой модели соответствуют прежде всего сопровождаемость и повторная используемость[22]. Экономика качества ПО связывает раннее выявление дефектов со снижением затрат: стоимость исправления дефекта растёт на поздних этапах жизненного цикла, поэтому автоматические проверки стиля и статический анализ выносятся на ранние этапы[23].

От языковых и корпоративных стандартов оформления PSR отличается порядком принятия: документы проходят голосование представителей проектов и признаются де-факто сообществом, а не утверждаются комитетом по стандартам[5].

Экономика качества ПО объясняет популярность такого пути: стандарты сообщества доходят до разработчиков в готовых инструментах, а проверки соответствия встраиваются в рутинные процессы раньше формальных аудитов. Международные стандарты качества при этом дают системы характеристик, в терминах которых эффект стандартизации описывается в исследованиях[22][23]. Рекомендации сознательно разграничивают уровни обязательности: часть правил сформулирована через «MUST» и обязательна для соответствия, часть — через «SHOULD» и «MAY», допуская последовательные локальные соглашения на уровне поставщика, пакета, класса или метода[9]. Ключевые слова требований заимствованы из RFC 2119 — того же документа, на котором строятся интернет-стандарты[9].

Ограничения и критика

PSR-стандарты — рекомендации, а не обязательные нормы: PHP не требует соответствия, и несоблюдающий стандарты код остаётся работоспособным[9]. Авторы обзоров отмечают ограничения консенсусной модели: после признания PSR-0 — PSR-4 стандартом де-факто попытки унифицировать более распространённые элементы приложений часто оказывались неудачными, а проект покидали участники, включая авторов Symfony, Laravel, Doctrine и Guzzle[4]. Три рекомендации — PSR-8, PSR-9 и PSR-10 — заброшены и остались в индексе с незанятыми номерами[3].

Долгие переходы между поколениями стандартов осложняют сопровождение: PSR-2 оставался действующим стилем кодирования до августа 2019 года, когда был принят PSR-12, — кодовые базы за это время накопили правила устаревшей рекомендации[7][8]. Инструменты смягчают проблему, автоматически форматируя код по новому стандарту, однако массовая перекодировка больших проектов остаётся заметной задачей[6].

Критики отмечают и незавершённость набора: четыре рекомендации остаются черновиками по многолетним срокам, включая стандарты документирования кода PSR-5 и PSR-19, значимые для инструментальной поддержки; пока документ не принят, он может измениться радикально[3]. Потребители стандартов в таких условиях ориентируются на принятые рекомендации, а анонсы черновиков воспринимают как сигналы направления, а не обязательства[3].

Связь с другими технологиями

PSR-стандарты связаны с ключевыми технологиями экосистемы PHP. Автозагрузка опирается на пространства имён, появившиеся в языке в 2009 году, и выполняется менеджером зависимостей Composer[6]. Стандарты процессов связаны с инфраструктурой разработки: проверки стиля и статический анализ встраиваются в непрерывную интеграцию и работают поверх репозиториев Git[4]. Интерфейсные рекомендации привязаны к интернет-стандартам: PSR-7 описывает HTTP-сообщения в терминах RFC 7230 и RFC 7231, а также URI по RFC 3986[13].

Смежные практики кодирования дополняют рекомендации. PHPDoc документирует код и стандартизируется черновиками PSR-5 и PSR-19, кэширование и журналирование получают стандартные интерфейсы PSR-6 и PSR-3, а модульное тестирование и открытая модель разработки формируют среду, в которой рекомендации принимаются сообществом[3][21]. Практики «чистого кода» и рефакторинга, описанные в профессиональной литературе, применяются совместно со стандартами оформления: единый стиль снижает стоимость чтения кода разными авторами[24][25].

Обзоры современной практики языка PHP относят единообразие оформления и повторное использование шаблонов проектирования к признакам зрелого кода, сопровождаемого командами[26][27].

Примечания

  1. ↑ Рекомендации к стандартам оформления кода на PHP. Михаил Кобзарев. Дата обращения: 10 октября 2026.
  2. ↑ 1 2 3 4 5 PHP-FIG — PHP Framework Interop Group (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  3. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 PHP Standards Recommendations (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  4. ↑ 1 2 3 4 5 6 7 8 9 10 Статический анализ кода PHP — держите свой код под контролем. Хабр (11 июля 2022). Дата обращения: 10 октября 2026.
  5. ↑ 1 2 3 4 5 Frequently asked questions (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  6. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 PSR Стандарты. Хабр. Дата обращения: 10 октября 2026.
  7. ↑ 1 2 PHP-Дайджест № 162 (1 – 12 августа 2019). Хабр (13 августа 2019). Дата обращения: 10 октября 2026.
  8. ↑ 1 2 3 4 PSR-12: Extended Coding Style (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  9. ↑ 1 2 3 4 5 6 7 8 PSR-1: Basic Coding Standard (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  10. ↑ 1 2 PSR-4: Autoloader (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  11. ↑ 1 2 PSR-3: Logger Interface (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  12. ↑ PSR-6: Caching Interface (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  13. ↑ 1 2 3 PSR-7: HTTP message interfaces (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  14. ↑ PSR-15: HTTP Server Request Handlers (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  15. ↑ 1 2 3 PSR-18: HTTP Client (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  16. ↑ PSR-11: Container interface (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  17. ↑ PSR-14: Event Dispatcher (англ.). PHP-FIG. Дата обращения: 10 октября 2026.
  18. ↑ Баранов А. Н., Баранова Е. М., Кулешова Н. В., Пелипенко В. А. Применение гибридного анализа для поиска уязвимостей в исходном программном коде // Вестник Евразийской науки. — 2022.
  19. ↑ Брусов А. С., Тарасов С. О. Использование фреймворка Laravel 5.0 для разработки web-приложений // Современные материалы, техника и технологии. — 2015.
  20. ↑ Гробер Т. А., Москаленко В. И. Разработка веб-приложения «Обучающий курс по SQL» // Молодой исследователь Дона. — 2022.
  21. ↑ 1 2 Карпунин А. А., Ганев Ю. М., Чернов М. М. Методы обеспечения качества при проектировании сложных программных систем // Надежность и качество сложных систем. — 2015.
  22. ↑ 1 2 Чумакова Т. Я., Цыганенко С. М. Построение модели качества программного обеспечения // Математические машины и системы. — 2009.
  23. ↑ 1 2 Лобанова Н. М., Дубровин Д. А. Оценка затрат на качество программного обеспечения // Вестник университета. — 2016.
  24. ↑ Martin R. Clean Code: A Handbook of Agile Software Craftsmanship. — Prentice Hall, 2008. — ISBN 9780132350884.
  25. ↑ Fowler M. Refactoring: Improving the Design of Existing Code. — Addison-Wesley, 2018. — ISBN 9780134757599.
  26. ↑ Lockhart J. Modern PHP: New Features and Good Practices. — O'Reilly Media, 2015. — ISBN 9781491905012.
  27. ↑ Zandstra M. PHP Objects, Patterns, and Practice. — Apress, 2013. — ISBN 9781430260318.

Литература

Cсылки

Дополнительно по теме

Категории

© Правообладателем данного материала является АНО «Интернет-энциклопедия «РУВИКИ».
Использование данного материала на других сайтах возможно только с согласия АНО «Интернет-энциклопедия «РУВИКИ».
Pause