NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Easy Coding Standard 2026

Was ist Easy Coding Standard?

Easy Coding Standard (ECS) ist ein Open Source Tool, das Regeln aus PHP CS Fixer und PHP_CodeSniffer in einem einzigen, parallelen Durchlauf auf euren PHP Code anwendet. Die komplette Konfiguration steckt in einer Datei namens ecs.php, und mit einem Befehl korrigiert ECS den Code automatisch.

Entwickelt wird ECS von Tomas Votruba, der auch hinter Rector steht. Das Tool läuft in Projekten mit PHP 7.2 bis PHP 8.5 und bringt keine eigenen Abhängigkeiten in euer Projekt. Damit gibt es keine Versionskonflikte mit Symfony, Laravel oder anderen Paketen im Vendor Ordner.

Der Kern der Idee: Ihr müsst weder PHP CS Fixer noch PHP_CodeSniffer im Detail kennen. ECS liefert fertige Regelsets, eine Konfiguration mit Autovervollständigung in der IDE und einen schrittweisen Einstieg über Levels. So bekommt jedes Team einen einheitlichen Code Stil, ohne tagelang Regeln zu diskutieren.

Inhalt

Easy Coding Standard mit NCA: Schnelle Hilfe vom Experten

NCA arbeitet täglich mit Symfony und PHP in Production. Unser Qualitätsfundament besteht aus PHPUnit, PHPStan, Psalm und Rector, die in GitHub Actions und GitLab CI bei jedem Push laufen. Roland Golla bringt über 20 Jahre Erfahrung in Testing und Refactoring mit und kennt die Diskussionen um Code Stil aus unzähligen Teams. Ein automatischer Coding Standard beendet diese Diskussionen, bevor sie im Code Review Zeit kosten.

Wir helfen euch beim PHP Refactoring gewachsener Codebasen, beim sicheren PHP Update auf aktuelle Versionen und bei der Legacy Modernisierung von PHP und Symfony Projekten. Für den Einsatz von KI im Team haben wir die NCA PHP AI Coding Guidelines entwickelt. Die passende Infrastruktur dazu bauen wir als CI CD Pipeline mit Docker und Staging.

Lass uns sprechen
Finde das passende Angebot für dein Projekt
Anfrage-Konfiguration
Starten Sie Ihre Anfrage
Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Installation und erster Lauf

ECS wird als Dev Abhängigkeit über Composer installiert:

Code: 
          
composer require symplify/easy-coding-standard --dev

Beim ersten Aufruf legt ECS selbst eine ecs.php im Projekt an. Darin stehen eure Verzeichnisse und eine erste Regel. Jeder weitere Lauf zeigt euch als Diff, was ECS ändern würde. Erst mit --fix schreibt das Tool die Änderungen wirklich in eure Dateien.

Code: 
          
# Prüfen und Diff anzeigen
vendor/bin/ecs

# Nur bestimmte Pfade prüfen
vendor/bin/ecs src tests

# Änderungen anwenden
vendor/bin/ecs --fix

Praktisch für Teams: vendor/bin/ecs scripts trägt die Befehle check-cs und fix-cs in eure composer.json ein. Dann lautet der Aufruf in jedem Projekt gleich, egal welches Tool dahinter steckt.

Konfiguration mit ECSConfig::configure()

Seit ECS 12.1 gibt es eine schlanke Konfiguration über die statische Methode ECSConfig::configure(). Die alte Schreibweise mit Closure und SetList Konstanten braucht ihr nicht mehr. Jede Methode beginnt mit with und wird in der IDE automatisch vervollständigt.

Code: 
          
use PhpCsFixer\Fixer\ArrayNotation\ArraySyntaxFixer;
use PhpCsFixer\Fixer\ListNotation\ListSyntaxFixer;
use Symplify\EasyCodingStandard\Config\ECSConfig;

return ECSConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withRootFiles()
    ->withRules([
        ListSyntaxFixer::class,
    ])
    ->withConfiguredRule(
        ArraySyntaxFixer::class,
        ['syntax' => 'short']
    )
    ->withPreparedSets(psr12: true);

Die wichtigsten Methoden:

  • withPaths: Welche Verzeichnisse geprüft werden.
  • withRootFiles: Nimmt alle PHP Dateien im Hauptverzeichnis mit, etwa ecs.php oder rector.php.
  • withRules und withConfiguredRule: Einzelne Regeln, mit oder ohne Optionen.
  • withPreparedSets: Fertige Regelsets von ECS.
  • withPhpCsFixerSets: Alle Sets aus PHP CS Fixer, zum Beispiel perCS20.
  • withSkip: Regeln oder Verzeichnisse gezielt ausschließen.
  • withEditorConfig: Übernimmt Einrückung und Zeilenenden aus eurer .editorconfig.

Prepared Sets in Easy Coding Standard

Mit withPreparedSets aktiviert ihr einzelne Themen oder mit common: true alle auf einmal.

Set Was es prüft Sinnvoll wenn
arrays Array Syntax, Abstände, Trailing Commas, Einrückung Arrays im Projekt uneinheitlich formatiert sind
spaces Leerzeichen, Operatoren, Leerzeilen Diffs voller Whitespace Änderungen sind
namespaces Reihenfolge und ungenutzte Imports use Statements wild gewachsen sind
docblocks PHPDoc Tags, Typen, Ausrichtung Doku Kommentare veraltet oder doppelt sind
controlStructures Kontrollfluss, Operatoren, Klassenstruktur Klassen einheitlich aufgebaut sein sollen
comments Kommentarstil und leere Kommentare Kommentare aufgeräumt werden sollen
casing Schreibweise von Funktionen, Typen, Literalen Groß und Kleinschreibung schwankt
cleanup Tote Anweisungen, unnötige Returns und Casts Legacy Code entrümpelt werden soll

Schrittweise Einführung mit Levels

Wer ECS auf ein großes Bestandsprojekt loslässt, bekommt schnell tausende Änderungen in einem Commit. Das will niemand reviewen. Deshalb bietet ECS Levels für einzelne Themen. Jedes Level schaltet die nächste Regel aus einer kuratierten Liste frei, sortiert von ungefährlich bis invasiv.

Code: 
          
use Symplify\EasyCodingStandard\Config\ECSConfig;

return ECSConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withSpacesLevel(0)
    ->withArrayLevel(0)
    ->withControlStructuresLevel(0)
    ->withDocblockLevel(0);

Ist der Code auf dem aktuellen Level sauber, erhöht ihr die Zahl um eins. So entstehen kleine, gut prüfbare Commits. Wichtig ist die Reihenfolge: Zuerst sichern Tests und Characterization Tests das Verhalten ab, dann räumt ECS den Stil auf. Ein Code Stil Tool verändert zwar keine Logik, aber große Diffs verdecken im Review echte Änderungen.

Ergänzend lohnt sich ein Blick auf Git Interactive Rebase, um reine Formatierungs Commits sauber von fachlichen Änderungen zu trennen.

ECS, PHP CS Fixer und PHP_CodeSniffer im Vergleich

ECS ersetzt die beiden bekannten Code Stil Tools nicht, es nutzt sie. Unter der Haube laufen die Regeln von PHP CS Fixer und PHP_CodeSniffer. ECS kümmert sich um Konfiguration, Parallelisierung, Cache und Ausgabe.

  • PHP CS Fixer hat Stärken bei der automatischen Korrektur und bringt fertige Sets wie Symfony oder PER Coding Style mit.
  • PHP_CodeSniffer ist geeignet für Projekte, die bestehende Sniffs nutzen, etwa aus WordPress oder PHPCompatibility.
  • ECS passt, wenn ihr Regeln aus beiden Welten kombinieren wollt und eine einzige, einfache Konfiguration bevorzugt.

Seit ECS 13.2 sind außerdem die Symplify eigenen Regeln direkt in ECS enthalten. Das separate Paket symplify/coding-standard ist damit überflüssig und als veraltet markiert. Wer nach Symfony Konventionen arbeitet, findet die Grundlagen im Artikel zu den Symfony Coding Standards. Wer Prüfungen schon vor dem Commit erzwingen will, kombiniert ECS mit GrumPHP.

Easy Coding Standard in der CI CD Pipeline

Ein Coding Standard wirkt erst, wenn er nicht umgangen werden kann. Deshalb gehört ECS in die Pipeline. Läuft der Check ohne --fix, bricht der Build bei jedem Verstoß ab. Ein Beispiel für GitHub Actions:

Code: 
          
name: Coding Standard

on: [push, pull_request]

jobs:
  ecs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.4'
      - run: composer install --no-progress
      - run: vendor/bin/ecs --output-format=checkstyle

Über --output-format liefert ECS Berichte in passenden Formaten:

  • checkstyle: für Annotationen in GitHub Actions.
  • gitlab: für Code Quality Reports in GitLab CI.
  • junit: für CI Systeme mit Test Übersichten.
  • json: für eigene Auswertungen.

In GitLab CI lohnt sich zusätzlich withCache mit festem Verzeichnis und Namespace. Sonst verwirft ECS den Cache bei jedem Job, weil sich der Pfad des Build Verzeichnisses ändert.

Easy Coding Standard als Leitplanke für KI Code

KI Agenten schreiben schnell, aber nicht immer im Stil eures Projekts. Mal fehlen Trailing Commas, mal landen Imports in falscher Reihenfolge, mal kommt ein veralteter Docblock dazu. Einzeln sind das Kleinigkeiten. In der Summe machen sie jedes Review mühsam.

Ein Coding Standard in der Pipeline ist hier eine einfache Leitplanke. Der Agent kann vendor/bin/ecs --fix selbst ausführen, bevor er einen Merge Request stellt. Im Review bleibt dann nur, was wirklich zählt: Logik, Architektur und Tests. Zusammen mit statischer Analyse und einer hohen Type Coverage entsteht so ein Rahmen, in dem generierter Code denselben Standard trifft wie handgeschriebener.

Wie solche Regeln im Team aussehen, beschreiben wir in den NCA PHP AI Coding Guidelines.

Easy Coding Standard focuses on easy run, setup, and use.

Tomas Votruba, Maintainer Easy Coding Standard und Rector – Blog tomasvotruba.com, Zen Config in ECS 12

Code Stil und Qualität in NCA Projekten

In unseren PHP Projekten gilt eine feste Reihenfolge: erst Qualitätstore, dann Aufräumen. PHPUnit und Functional Tests sichern das Verhalten ab, PHPStan und Psalm finden Typfehler, Rector modernisiert den Code. Ein Coding Standard sorgt am Ende dafür, dass alles gleich aussieht. ECS ist geeignet für Teams, die Regeln aus PHP CS Fixer und PHP_CodeSniffer bündeln wollen. Wir helfen euch, ECS gegen einen reinen PHP CS Fixer Einsatz abzuwägen.

Bei gewachsenen Codebasen setzen wir nicht auf den großen Wurf in einem Commit. Wir führen Regeln schrittweise ein, trennen Formatierung von Fachlogik und halten jede Änderung reviewbar. Für die Ablösung alter Systeme nutzen wir Muster wie das Strangler Fig Pattern, statt im Legacy Code endlos weiterzubauen. Mehr dazu findet ihr bei unserer Legacy Modernisierung.

Jede Zusammenarbeit beginnt mit einem kostenlosen Kennenlernen. Danach schätzen wir den Aufwand realistisch und rechnen transparent auf die Minute ab. Weitere Werkzeuge rund um Code Qualität findet ihr im NCA PHP Glossar, zum Beispiel Deptrac für Architekturregeln.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zu Easy Coding Standard

Die wichtigsten Antworten zu Installation, Konfiguration und Einsatz von ECS im Team.

Welche PHP Versionen unterstützt Easy Coding Standard 2026?

ECS läuft in Projekten mit PHP 7.2 bis PHP 8.5. Möglich macht das ein vorkompiliertes Paket ohne eigene Abhängigkeiten. Dadurch kollidiert ECS nicht mit Symfony, Laravel oder anderen Bibliotheken in eurem Vendor Ordner. Auch ältere Projekte vor einem PHP Update lassen sich so mit einem einheitlichen Code Stil absichern.

Wie sieht die ecs.php Konfiguration 2026 aus?

Die Konfiguration nutzt ECSConfig::configure() mit verketteten Methoden wie withPaths, withRules und withPreparedSets. Diese Schreibweise gibt es seit ECS 12.1. Die ältere Variante mit Closure und SetList Konstanten solltet ihr bei Gelegenheit umstellen. Die neue Syntax ist kürzer und wird in PhpStorm oder VS Code automatisch vervollständigt.

Brauche ich symplify/coding-standard 2026 noch?

Nein. Seit ECS 13.2 sind die Symplify Regeln direkt in ECS enthalten. Das separate Paket ist als veraltet markiert. Entfernt es aus eurer composer.json und aktualisiert ECS. Eure ecs.php müsst ihr dafür nicht anpassen, weil die Klassennamen der Regeln gleich geblieben sind.

ECS oder PHP CS Fixer: Was passt 2026 besser?

Das hängt vom Projekt ab. PHP CS Fixer reicht, wenn ihr nur dessen Regeln nutzt. ECS lohnt sich, wenn ihr Regeln aus PHP CS Fixer und PHP_CodeSniffer kombinieren wollt, eine einfache Konfiguration bevorzugt oder Regeln schrittweise über Levels einführen möchtet. Beide Tools laufen gut in CI Pipelines.

Wie führe ich ECS 2026 in ein bestehendes Projekt ein?

Startet mit den Levels, zum Beispiel withSpacesLevel(0) und withArrayLevel(0). So aktiviert ihr nur die ungefährlichsten Regeln und erhöht das Level Schritt für Schritt. Trennt Formatierungs Commits von fachlichen Änderungen. Dadurch bleiben Reviews übersichtlich und die Git Historie nachvollziehbar.

Wie schließe ich Regeln oder Verzeichnisse aus?

Dafür gibt es withSkip. Ihr könnt eine Regel komplett ausschalten, eine Regel nur für bestimmte Pfade abschalten oder ganze Verzeichnisse ignorieren. Auch Muster mit Sternchen sind möglich, etwa für alle Legacy Ordner. So bleiben Migrationen oder generierter Code außen vor, ohne die Regeln für den Rest aufzuweichen.

Kann ECS meine .editorconfig nutzen?

Ja, weitgehend. Mit withEditorConfig liest ECS die .editorconfig im Projektverzeichnis. Übernommen werden unter anderem Einrückung, Zeilenenden, maximale Zeilenlänge, abschließende Leerzeichen und die Leerzeile am Dateiende. Diese Werte haben Vorrang vor ähnlichen Regeln aus Sets wie PSR 12, damit sich eure Tools nicht widersprechen.

Wie zeige ich ECS Ergebnisse in GitHub oder GitLab an?

Nutzt die Option --output-format. Mit checkstyle erscheinen Verstöße als Annotationen in GitHub Actions. Mit gitlab erzeugt ECS einen Code Quality Report, den GitLab direkt im Merge Request anzeigt. Zusätzlich gibt es junit für CI Systeme mit Test Übersicht und json für eigene Auswertungen.

Wie leere ich den ECS Cache?

Mit vendor/bin/ecs --clear-cache. ECS merkt sich geprüfte Dateien und prüft beim nächsten Lauf nur Änderungen. Das spart viel Zeit. Wenn ihr Regeln ändert und Ergebnisse unerwartet ausfallen, hilft ein geleerter Cache. In CI Umgebungen könnt ihr Verzeichnis und Namespace des Cache mit withCache festlegen.

Welche Regeln sind in meinem Projekt aktiv?

Der Befehl vendor/bin/ecs list-checkers zeigt alle aktiven Regeln aus eurer Konfiguration. Mit der Option --output-format json bekommt ihr die Liste maschinenlesbar. Das hilft bei der Dokumentation eures Coding Standards und bei der Frage, warum ECS eine bestimmte Stelle im Code verändert hat.

Läuft ECS parallel?

Ja. ECS verteilt die Prüfung standardmäßig auf mehrere Prozesse. Das macht auch große Codebasen schnell. Über withParallel könnt ihr Timeout, Anzahl der Prozesse und Größe der Pakete anpassen. Das ist selten nötig, kann aber auf kleinen CI Runnern oder sehr großen Monorepos sinnvoll sein.

Ersetzt ECS statische Analyse wie PHPStan?

Nein. ECS kümmert sich um den Stil des Codes, also Formatierung, Imports und Schreibweisen. PHPStan und Psalm prüfen Typen und finden logische Fehler, bevor sie in Production landen. Beide Ebenen ergänzen sich. In einer sauberen Pipeline laufen Tests, statische Analyse und Coding Standard gemeinsam bei jedem Push.