In PHP, what are the PSR-1 and PSR-12 coding standards, and what kinds of rules does each one set?
answer
- PHP-FIG recommendations
- basic interoperability versus formatting
- StudlyCaps, camelCase, UPPER_CASE
- 4 spaces, LF, no closing tag
- PSR-12 replaced PSR-2
basics
~20 sPSR-1 is PHP-FIG's basic coding standard: tags, UTF-8, naming, one class per autoloadable file, and no mixing of declarations with side effects. PSR-12 extends it with formatting: indentation, line endings, braces, spacing and file-header order, replacing PSR-2.
solid answer
~40 sBoth are PHP Standard Recommendations from the PHP Framework Interoperability Group (PHP-FIG). **PSR-1**, the *Basic Coding Standard*, covers what shared code needs to interoperate: only `<?php` and `<?=` tags, UTF-8 without BOM, a file either declares symbols or causes side effects, classes follow an autoloading PSR, class names in `StudlyCaps`, class constants in `UPPER_CASE` with underscores, methods in `camelCase`. It deliberately says nothing about property naming beyond consistency. **PSR-12**, the *Extended Coding Style Guide*, requires PSR-1 and adds the layout rules: 4-space indentation and no tabs, Unix LF line endings, the closing `?>` omitted in PHP-only files, a 120-character soft line limit, lowercase keywords and short type names, a fixed order of header blocks, and brace and spacing rules for classes, methods, control structures and closures. PSR-12 replaced PSR-2, which is deprecated.
go deeper
Remember that PSR-1 is the basics (tags, encoding, naming, side effects) and PSR-12 the full formatting guide built on it. Know the three casings: StudlyCaps classes, camelCase methods, UPPER_CASE class constants.
Explain the split between interoperability rules and layout rules, name a handful of PSR-12 requirements precisely, and know that PSR-2 is deprecated in favour of PSR-12.
Talk about adopting the standard in a real codebase: which rules are MUST versus SHOULD, why a frozen PSR-12 leaves newer syntax uncovered, and how PER Coding Style continues it.
Frame the choice as an ecosystem one: following the shared PHP-FIG style lowers onboarding and review cost, and deviations need a reason worth that cost.
## Who writes these rules The **PHP Framework Interoperability Group (PHP-FIG)** publishes **PHP Standard Recommendations (PSRs)**. Some PSRs define interfaces that libraries share, such as logging or HTTP messages. Two of them define how code looks: - **PSR-1, Basic Coding Standard**: the minimum that shared PHP code should agree on. - **PSR-12, Extended Coding Style Guide**: a full formatting guide that builds on PSR-1. Both use RFC 2119 keywords: **MUST** is a requirement, **SHOULD** is a strong recommendation with room for exceptions, **MAY** is optional. ## PSR-1 in one list | Rule | Requirement | |---|---| | PHP tags | only `<?php ?>` and the short-echo `<?= ?>` | | Encoding | UTF-8 without BOM | | Side effects | a file SHOULD declare symbols **or** cause side effects, not both | | Namespaces and classes | follow an autoloading PSR; one class per file, at least a vendor namespace | | Class names | `StudlyCaps` (PSR-12 clarifies: PascalCase, first letter capitalised) | | Class constants | all upper case with underscores, such as `DATE_APPROVED` | | Method names | `camelCase` | | Property names | no rule; be consistent within a vendor, package, class or method | PSR-1 is about **interoperability**: code from different vendors can be autoloaded and read side by side without surprises. ## PSR-12 in outline PSR-12 says code MUST follow PSR-1, then adds: 1. **Files**: Unix LF line endings only; end with a single newline; omit the closing `?>` in files containing only PHP. 2. **Lines**: no hard limit, a 120-character soft limit, lines SHOULD stay under 80; no trailing whitespace; one statement per line. 3. **Indentation**: 4 spaces, never tabs. 4. **Keywords and types**: lowercase, including keywords added in future PHP versions; short type names (`bool`, `int`, not `boolean`, `integer`). 5. **File header**: a fixed order of blocks, each separated by one blank line: opening tag, file docblock, `declare` statements, `namespace`, class imports, function imports, constant imports, then the code. 6. **Classes**: `extends` and `implements` on the class line; the opening brace of a class or method on its own line; visibility on every property, method and (from PHP 7.1) constant; no `var`; no underscore prefixes to signal visibility; `abstract` and `final` before visibility, `static` after it. 7. **Control structures**: one space after the keyword, the opening brace on the same line, a body always in braces, `elseif` rather than `else if`. 8. **Closures and anonymous classes**: the opening brace on the same line, a space after `function` and around `use`. ## A short example ```php <?php declare(strict_types=1); namespace Acme\Billing; use Acme\Billing\Tax\TaxRate; final class InvoiceLine { public const DEFAULT_QUANTITY = 1; public function __construct( private readonly string $sku, private readonly int $quantity = self::DEFAULT_QUANTITY, ) { } public function totalCents(int $unitPriceCents, TaxRate $rate): int { if ($this->quantity <= 0) { return 0; } return $rate->apply($unitPriceCents * $this->quantity); } } ``` The class name is PascalCase, the constant upper case, methods camelCase; the class and method braces sit on their own lines, the `if` brace on the same line. A multi-line parameter list ends with `) {` on its own line. ## MUST versus SHOULD in practice Most of PSR-12 is MUST, but several important rules are SHOULD: the 80-character preference, `elseif` over `else if`, and PSR-1's side-effects rule. A SHOULD allows a justified exception, so a checker configured strictly may flag code that is still compliant. When a team adopts the standard, it helps to decide up front which SHOULD rules it treats as mandatory, so the check and the reviewers agree. ## Why teams adopt them - **Less friction when reading other people's code**: every package on Packagist that follows PSR-12 looks alike. - **No style debates**: a named standard ends arguments about braces and tabs. - **Tool support**: formatters and sniffers ship presets for PSR-12, so style becomes a check rather than a review comment. As PSR-12 itself says, the benefit is not in the rules themselves but in sharing them. ## Where things stand now PSR-2, the earlier style guide, was deprecated in 2019 in favour of PSR-12. PSR-12 is frozen, as accepted PSRs are, so it does not cover syntax added after it. PHP-FIG continues that work in **PER Coding Style**, an evolving recommendation with numbered releases that builds on PSR-12.
- Does PSR-1 say whether properties should be named $camelCase or $snake_case?No. PSR-1 intentionally avoids a rule for property names; it asks only that whatever convention you use is applied consistently within a reasonable scope, such as a vendor, package, class or method. Class names, class constants and method names are the ones with required casing.
- Is a project that follows PSR-12 automatically compliant with PSR-1?Yes, by definition: PSR-12 states that code MUST follow all rules in PSR-1, so PSR-1 is a subset of it. The reverse is not true; PSR-1 compliant code can use tabs, put braces anywhere and still pass PSR-1, because PSR-1 does not address layout.
saying these in an interview costs you the question
- Says PSR-2 is still the current PHP-FIG coding style standard.
- Believes PSR-1 prescribes indentation, braces and line length.
- Claims PSR-1 requires camelCase property names.
- Thinks PSR-12 requires a hard 80-character line limit.
- Describes PSRs as rules the PHP engine itself enforces.