PHP Standard Recommendations (PSRs) are guidelines published by the PHP-FIG (PHP Framework Interoperability Group) to standardize PHP code and improve interoperability. Below is a summary of the most commonly referenced PSRs:

PSR-1: Basic Coding Standard

  • Purpose: Defines basic coding standards for PHP.
  • Key Points:
    • Files must use only <?php and <?= tags.
    • Class names should be in StudlyCaps.
    • Method names should be in camelCase.
    • Constants should be in uppercase with underscores separating words.

PSR-2: Coding Style Guide

  • Purpose: Provides guidelines for coding style to improve readability and consistency.
  • Key Points:
    • Code should be indented with 4 spaces.
    • Lines should not exceed 120 characters.
    • Braces should be on the same line as the declaration.
    • Method and function names should be in camelCase.

PSR-3: Logger Interface

  • Purpose: Defines a standard interface for logging libraries.
  • Key Points:
    • Provides Psr\Log\LoggerInterface with methods like emergency(), alert(), critical(), error(), etc.
    • Ensures consistency across different logging libraries.

PSR-4: Autoloading Standard

  • Purpose: Specifies a standard for autoloading classes using namespaces.
  • Key Points:
    • Classes should be in files that match their fully qualified class name.
    • Allows for autoloading based on namespace and class name.

PSR-7: HTTP Message Interface

  • Purpose: Defines interfaces for HTTP messages, including requests and responses.
  • Key Points:
    • Defines Psr\Http\Message\RequestInterface and Psr\Http\Message\ResponseInterface.
    • Provides methods for working with HTTP headers, body, and status codes.

PSR-12: Extended Coding Style Guide

  • Purpose: Extends PSR-2 to provide a more comprehensive coding style guide.
  • Key Points:
    • Builds upon PSR-2 with additional rules and guidelines.
    • Enhances code consistency and readability.

PSR-15: HTTP Server Request Handlers

  • Purpose: Defines interfaces for handling HTTP server requests.
  • Key Points:
    • Provides Psr\Http\Server\RequestHandlerInterface for handling requests and generating responses.

PSR-16: Simple Cache

  • Purpose: Defines a simple caching interface.
  • Key Points:
    • Provides Psr\SimpleCache\CacheInterface with methods for basic cache operations like get(), set(), delete(), etc.

PSR-17: HTTP Factories

  • Purpose: Provides factories for creating PSR-7 compliant HTTP messages.
  • Key Points:
    • Includes interfaces for creating request, response, and server request objects.

PSR-18: HTTP Client

  • Purpose: Defines a standard interface for HTTP clients.
  • Key Points:
    • Provides Psr\Http\Client\ClientInterface for sending HTTP requests and receiving responses.

Why PSRs Matter

PSRs let libraries interoperate without adapter layers. When a package type-hints Psr\Log\LoggerInterface, you can swap Monolog, Symfony Console, or any PSR-3 implementation without changing calling code.

Applying PSR-12 in Practice

Use PHP-CS-Fixer or PHP_CodeSniffer to enforce style automatically:

  composer require --dev friendsofphp/php-cs-fixer
vendor/bin/php-cs-fixer fix src/

A PSR-12 compliant class uses 4-space indentation, opening braces on the same line for methods, and one blank line between methods.

PSR-3 Logger Example 

  use Psr\Log\LoggerInterface;

class OrderService {
    public function __construct(private LoggerInterface $logger) {}

    public function placeOrder(int $orderId): void {
        $this->logger->info('Order placed', ['order_id' => $orderId]);
    }
}

PSR-7 HTTP Messages

Frameworks like Slim and Laminas build on PSR-7. Requests and responses are immutable — each withHeader() call returns a new instance:

  $response = $response
    ->withHeader('Content-Type', 'application/json')
    ->withStatus(200);

Deprecated vs Current Standards

Old Current Notes
PSR-1, PSR-2 PSR-12 PSR-2 is deprecated; use PSR-12
None PSR-11 Container interface for DI

Common Pitfalls

  • Assuming every package follows PSRs — check README and composer.json provide/require sections.
  • Mixing coding styles across a team — automate formatting in CI.
  • Ignoring PSR-4 when publishing packages — incorrect autoload paths break consumers.