Hvad er PSR-standarder, og hvorfor betyder de noget?

Question

Accepted Answer

**PSRs (PHP Standard Recommendations)** er et sæt standarder udgivet af **PHP-FIG** (Framework Interoperability Group), der definerer almindelige konventioner — kodestil, autoloading og delte interfaces — som muliggør **interoperabilitet** mellem forskellige PHP-frameworks, biblioteker og pakker.

## De vigtigste PSR'er

```text
PSR-1 / PSR-12 → CODING STYLE (basic + extended): naming, braces, indentation, etc.
PSR-4         → AUTOLOADING: namespace ↔ directory mapping (used by Composer)
PSR-3         → LoggerInterface: a common logging interface
PSR-7         → HTTP message interfaces (Request/Response objects)
PSR-11        → ContainerInterface: a common DI container interface
PSR-15        → HTTP middleware interface
PSR-6 / PSR-16 → Caching interfaces
PSR-18        → HTTP client interface
```

## PSR-4 autoloading (den du bruger dagligt)

```json
// composer.json — PSR-4 maps namespaces to directories
{ "autoload": { "psr-4": { "App\": "src/" } } }
// App\Models\User → src/Models/User.php — Composer autoloads it automatically
```

PSR-4 er den autoloading-standard, som al moderne PHP er afhængig af — det er grunden til, at Composer kan finde og indlæse enhver klasse efter dens namespace.

## PSR-interfaces muliggør interoperabilitet

```php
// because libraries depend on the PSR-3 LoggerInterface (not a concrete logger),
// you can swap ANY PSR-3-compliant logger (Monolog, etc.) without changing code
use Psr\Log\LoggerInterface;

class Service {
    public function __construct(private LoggerInterface $logger) {}   // PSR-3 interface
}
// inject Monolog, or any PSR-3 logger — the service doesn't care which
```

Delte interfaces (PSR-3 logging, PSR-7 HTTP, PSR-11 container) betyder, at biblioteker kan afhænge af en *standardinterface* i stedet for en specifik implementering — så komponenter fra forskellige leverandører er **udskiftelige**.

## PSR-12 kodestil (konsistens)

```text
PSR-12 defines a standard code style (spacing, brace placement, naming).
Following it → consistent code across teams and projects; tools (PHP-CS-Fixer,
PHPCS) auto-format/check against it. Most modern PHP projects adopt PSR-12.
```

## Hvorfor det betyder noget

PSR-standarder er vigtige for professionel PHP-udvikling, fordi de muliggør den **interoperabilitet**, som gør det moderne PHP-økosystem muligt — uden fælles standarder kunne frameworks og biblioteker fra forskellige kilder ikke let arbejde sammen.

At forstå dem er værdifuldt af flere grunde. **PSR-4 autoloading** er grundlæggende og bruges dagligt — det er namespace-til-mappe-standarden, som Composer er afhængig af for at indlæse klasser automatisk, hvilket ligger til grund for ethvert moderne PHP-projekts struktur.

De **delte interface PSR'er** (PSR-3 logging, PSR-7 HTTP-meddelelser, PSR-11 containers, PSR-15 middleware) er det, der tillader komponenter fra forskellige leverandører at være udskiftelige: fordi biblioteker afhænger af en *standardinterface* i stedet for en konkret implementering, kan du udskifte enhver kompatibel implementering (enhver PSR-3 logger, ethvert PSR-7 HTTP-bibliotek) uden at ændre kode — en kraftig muliggør af fleksibel, afkoblet arkitektur og grunden til, at PHP-økosystemets dele passer sammen. **PSR-12 kodestil** bringer konsistens på tværs af hold og projekter (håndhævet af værktøjer), som de fleste moderne PHP vedtager.

At kende de vigtigste PSR'er — især PSR-4 (autoloading), interface-standarderne (interoperabilitet) og PSR-12 (stil) — og PHP-FIGs rolle afspejler professionel forståelse af, hvordan det moderne PHP-økosystem opnår konsistens og interoperabilitet.

Da det at følge PSR'er er standard praksis i professionel PHP, og da de ligger til grund for Composer, framework-interoperabilitet og kodekvalitet, er forståelsen af dem værdifuld senior-niveau viden, der adskiller udviklere, der skriver økosystem-kompatibel, professionel PHP, fra dem, der er uvidende om de konventioner, som gør moderne PHP sammenhængende og interoperabel.