skip to content

In PHP-FIG terms, why are PSR-2 and PSR-0 deprecated, and how does PER Coding Style differ from PSR-12?

level: middleimportance: should knowfreq 30%

answer

  1. superseded, not broken
  2. PSR-0 by PSR-4 in 2014
  3. PSR-2 by PSR-12 in 2019
  4. PSRs are frozen once accepted
  5. PERs evolve with semantic versions

basics

~20 s

PSR-0 was deprecated in 2014 in favour of PSR-4 autoloading, and PSR-2 in 2019 in favour of PSR-12. Accepted PSRs are frozen, so style work continues in PER Coding Style, a versioned, evolving recommendation built on PSR-12.

solid answer

~40 s

A PSR moves through workflow statuses: **Draft**, **Review**, **Accepted**, and later possibly **Deprecated**, or **Abandoned** if its working group dissolves before acceptance. Deprecated means approved but no longer recommended, usually because a newer PSR supersedes it. **PSR-0** (autoloading) was deprecated on 2014-10-21 with **PSR-4** recommended instead; **PSR-2** (coding style) on 2019-08-10 with **PSR-12**. PSR-12 itself says it extends, expands and replaces PSR-2, because PHP had gained syntax PSR-2 never addressed. Accepted PSRs are **frozen**, which is exactly why style needed a different vehicle: a **PHP Evolving Recommendation (PER)** is versioned with Semantic Versioning and can be re-released as the language changes. **PER Coding Style** began from PSR-12's content and has had 1.0, 2.0 and 3.0 releases covering newer syntax, for example trailing commas in multi-line lists.

go deeper

for a junior

Know that PSR-2 and PSR-0 are deprecated: PSR-12 replaced PSR-2 and PSR-4 replaced PSR-0. Current style work continues in PER Coding Style.

for a middle

Explain the difference between a frozen PSR and a versioned PER, and list the PSR statuses from Draft to Deprecated and Abandoned.

for a senior

Advise on standard choice and migration: pin a PER Coding Style version, plan major-version upgrades as single formatting changes, and clean out references to PSR-2 in tooling and docs.

for a principal

Weigh stability against currency: a frozen standard never surprises you but ages; an evolving one stays current but needs a deliberate upgrade policy.

## Two kinds of PHP-FIG output PHP-FIG's bylaws define two kinds of recommendation: - A **PHP Standard Recommendation (PSR)** is developed to a particular end state and, once approved, is **frozen in time** to give implementers a stable target, with narrow exceptions under the amendment and evolution bylaws. Clarifications after acceptance go into an **errata** section of its meta document. - A **PHP Evolving Recommendation (PER)** is a set of best practices or guidelines expected to **change as the PHP language and ecosystem change**. Its artifacts follow **Semantic Versioning**: bugfix releases at any time, minor releases after the maintainer announces an intent to merge to the Core Committee, and major releases only with a Core Committee approval vote. Coding style is the obvious case for a PER: every PHP release adds syntax (enums, attributes, property hooks, the pipe operator) that a frozen style guide cannot mention. ## The PSR workflow statuses | Status | Meaning | |---|---| | Pre-Draft | an idea looking for an Entrance Vote from the Core Committee | | Draft | accepted for work and given a number; may change drastically | | Review | trial implementations; only minor changes; at least four weeks and two viable implementations before acceptance | | Accepted | final; the editor becomes maintainer | | Deprecated | approved but no longer considered relevant or recommended, typically superseded | | Abandoned | not being worked on, for example because its working group dissolved | A PSR is deprecated either as part of the acceptance vote for its replacement or through a separate deprecation vote. ## Why PSR-0 and PSR-2 are deprecated - **PSR-0** was the first autoloading standard. It was deprecated on **2014-10-21**, and **PSR-4** is recommended instead. PSR-4 is the autoloading scheme Composer projects use today; its rules belong to the autoloading topic. - **PSR-2** was the first coding style guide, accepted in 2012. It was deprecated on **2019-08-10**, and **PSR-12** is recommended instead. PSR-12's overview explains why: PHP had changed a lot since 2012, new functionality was "very open to interpretation" under PSR-2, and PSR-12 also made the PSR-2 errata binding. "Deprecated" does not mean the old rules are wrong. PSR-12 is largely a superset of PSR-2. It means new projects should not target them and tools and documentation should not present them as current. ## From PSR-12 to PER Coding Style PSR-12 was accepted in 2019 and, being a PSR, it stays as written. PER Coding Style continues it: 1. **1.0** started from PSR-12's content as an evolving document. 2. **2.0** added rules for syntax and idioms PSR-12 did not settle, for example trailing commas in multi-line argument, parameter and array lists, and one space around the concatenation operator. 3. **3.0** is the latest release, and continues with newer syntax. Because PER releases are versioned, a project states which one it follows ("PER Coding Style 3.0"), much as it pins a dependency. A major release can require changes that the previous release forbade, so moving from one to the next is a deliberate step, usually with one formatting commit. ## How to tell what a project follows When you join a project or evaluate a package, the standard is usually visible in a few places: - the contributing guide or README, which should name the standard and version; - the configuration files of the formatter or sniffer, where the chosen preset shows whether it is PSR-12, a PER release, or a custom set; - the code itself: trailing commas in every multi-line argument list and one space around `.` suggest PER Coding Style 2.0 or later rather than bare PSR-12. If the configuration still names PSR-2, the project predates 2019 or has not revisited its tooling since. ## What this means in practice - A new project in 2026 targets **PER Coding Style** at a stated version, or at minimum PSR-12. - Documentation or tool configuration that names **PSR-2** as the standard is out of date. - Code or docs that mention **PSR-0** are describing a deprecated autoloading scheme. - PSR-1 is still **accepted** and remains the base that PSR-12 and PER Coding Style build on.

  • If a project follows PSR-12, is it violating a deprecated standard by also satisfying most of PSR-2?
    No. Deprecation is about what should be recommended, not about the rules being wrong. PSR-12 extends and replaces PSR-2 and keeps most of its rules, so PSR-12 code naturally satisfies much of PSR-2. The point is that PSR-12, or PER Coding Style, is the standard to name and configure tools against.
  • Why could PHP-FIG not simply update PSR-12 for enums, attributes and newer syntax?
    Accepted PSRs are frozen by the bylaws to give implementers a stable target; only errata clarifications and narrow amendment or evolution procedures are allowed. Adding new style rules would change what compliance means. A PER is designed for exactly that kind of change, with Semantic Versioning to signal how disruptive each release is.

A PSR is like a printed national standard: once published it never changes, so a revision needs a new number. A PER is like a style manual that comes out in numbered editions; you cite the edition you follow, and upgrading to the next is your decision.

saying these in an interview costs you the question

  • Names PSR-2 as the current PHP coding style standard.
  • Believes a deprecated PSR contains rules that are now considered wrong.
  • Thinks PSR-12 is regularly updated to cover new PHP syntax.
  • Treats PER Coding Style as an unofficial community fork of PSR-12.
  • Recommends PSR-0 for autoloading in a new Composer package.