Jede Regel. Eine ID.

Stabile Regel-IDs halten Website, Checker, CLI, Formatter und IDE-Integrationen konsistent. 112 Regeln, 51 davon automatisch prüfbar.

ID	Regel	Profil
`PL-CORE-001`	Kontrollfluss so linear wie möglich	Core
`PL-CORE-002`	else vermeiden	Core
`PL-CORE-003`	Guard Clauses bevorzugen	Core
`PL-CORE-004`	Die klarste Kontrollfluss-Form der Sprache; Klammer-Sprachen nutzen explizite Blöcke	Core
`PL-CORE-005`	Idiomatische Kurzformen sind erlaubt, solange sie sofort lesbar bleiben	Core
`PL-CORE-006`	Funktionen klein und fokussiert	Core
`PL-CORE-007`	Namen tragen Bedeutung	Core
`PL-CORE-008`	Keine unnötigen Abstraktionen	Core
`PL-CORE-009`	Keine God Classes und God Modules	Core
`PL-CORE-010`	Immutable State bevorzugen	Core
`PL-CORE-011`	Moderne Sprachfeatures, wo sie Klarheit schaffen	Core
`PL-CORE-012`	Keine unnötige vertikale Formatierung	Core
`PL-CORE-013`	Kommentare kompensieren keinen unklaren Code	Core
`PL-CORE-014`	Ungültige und Fehlerzustände früh behandeln	Core
`PL-CORE-015`	Wichtige Seiteneffekte sichtbar halten	Core
`PL-CORE-016`	Ressourcen haben einen klaren Lebenszyklus	Core
`PL-CORE-017`	Framework-native APIs bevorzugen	Core
`PL-CORE-018`	Magic Values vermeiden	Core
`PL-CORE-019`	Abhängigkeiten explizit machen	Core
`PL-CORE-020`	Hot Paths bewusst optimieren, nicht zufällig	Core
`PL-CORE-021`	Pakete und Quellordner klein genug halten, um sie auf einen Blick zu überblicken	Core
`PL-CORE-022`	Cohesion over Size: eine zusammenhängende Verantwortung statt willkürlicher Zeilenlimits für Klassen	Core
`PL-CF-001`	Guard Clauses bevorzugen	Core
`PL-CF-002`	else vermeiden	Core
`PL-CF-003`	Explizite Blöcke in Klammer-Sprachen	Core
`PL-NAME-001`	Namen tragen Bedeutung	Core
`PL-FN-001`	Eine klare Verantwortung pro Funktion	Core
`PL-STRUCT-001`	Eine klare Verantwortung pro Klasse und Modul	Core
`PL-STRUCT-002`	Pakete und Ordner klein genug zum Überblicken	Core
`PL-STRUCT-003`	Zusammengehörigkeit vor Zeilenbegrenzung	Core
`PL-ARCH-001`	Abstraktion braucht einen Grund	Core
`PL-FMT-001`	Kompakte horizontale Aufrufe	Core
`PL-DOC-001`	Kommentare erklären das Warum	Core
`PL-JAVA-001`	Packages nach Verantwortung	Java
`PL-JAVA-002`	Naming	Java
`PL-JAVA-003`	Records für immutable Daten	Java
`PL-JAVA-004`	Explizites Null-Handling	Java
`PL-JAVA-005`	Imports statt FQCNs	Java
`PL-JAVA-006`	Modernes Java bevorzugen	Java
`PL-JAVA-007`	switch für echte Zustandsverzweigung	Java
`PL-JAVA-008`	Nebenläufigkeit	Java
`PL-JAVA-009`	Streams nur, wenn klarer	Java
`PL-JAVA-010`	Lifecycle-Symmetrie	Java
`PL-JS-001`	Braces sind Pflicht	JavaScript
`PL-JS-002`	Semikolons verwenden	JavaScript
`PL-JS-003`	const zuerst	JavaScript
`PL-JS-004`	async / await bevorzugen	JavaScript
`PL-JS-005`	Arrow Functions im Kontext	JavaScript
`PL-JS-006`	Destructuring muss Klarheit schaffen	JavaScript
`PL-JS-007`	Folder Density	JavaScript
`PL-TS-001`	any vermeiden	TypeScript
`PL-TS-002`	Typen bewusst einsetzen	TypeScript
`PL-TS-003`	Kein I-Prefix	TypeScript
`PL-TS-004`	interface vs. type	TypeScript
`PL-TS-005`	Union Types statt Enums	TypeScript
`PL-TS-006`	Starke Typen an Grenzen, Freiheit im Inneren	TypeScript
`PL-TS-007`	Folder Density	TypeScript
`PL-GO-001`	Error Guards	Go
`PL-GO-002`	Kein else nach terminierenden Zweigen	Go
`PL-GO-003`	Idiomatische Namen	Go
`PL-GO-004`	Kurze Receiver-Namen sind erlaubt	Go
`PL-GO-005`	Kleine Interfaces	Go
`PL-GO-006`	Interfaces beim Konsumenten definieren	Go
`PL-GO-007`	defer für klare Lebenszyklen	Go
`PL-GO-008`	Goroutines brauchen Ownership	Go
`PL-GO-009`	Keine voreilige Interface-Abstraktion	Go
`PL-CR-001`	Idiomatische Postfix-Guards sind erlaubt	Crystal
`PL-CR-002`	else vermeiden	Crystal
`PL-CR-003`	Idiomatische Namen	Crystal
`PL-CR-004`	Typinferenz bevorzugen	Crystal
`PL-CR-005`	Explizite nil-Guards	Crystal
`PL-CR-006`	Exceptions für Ausnahmezustände	Crystal
`PL-CR-007`	Keine Macro-Cleverness ohne Not	Crystal
`PL-CR-008`	Folder Density	Crystal
`PL-EV-001`	Native Methodendeklarationen	Emvus
`PL-EV-002`	Leere Deklarationsklammern optional, Aufrufklammern nicht	Emvus
`PL-EV-003`	Braces Pflicht, Semikolons optional	Emvus
`PL-EV-004`	Naming, Imports und Sichtbarkeit	Emvus
`PL-EV-005`	Typen sollen Absicht vermitteln	Emvus
`PL-EV-006`	Nullability über stabilen Kontrollfluss behandeln	Emvus
`PL-EV-007`	Typisierte Result-Behandlung für erwartete Fehler	Emvus
`PL-EV-008`	Ressourcenlebensdauer mit `scoped` sichtbar machen	Emvus
`PL-EV-009`	Data Classes statt Boilerplate	Emvus
`PL-EV-010`	Listen, Tupel und Dictionaries behalten ihre Semantik	Emvus
`PL-EV-011`	Destructuring ist positional	Emvus
`PL-EV-012`	`switch` soll vollständige Verzweigung zeigen	Emvus
`PL-EV-013`	Cascades nur für einen einzelnen Receiver	Emvus
`PL-EV-014`	Fibers und Threads brauchen klare Lebenszyklen	Emvus
`PL-EV-015`	Macros sollen Auffindbarkeit verbessern, nicht verschleiern	Emvus
`PL-EV-016`	Nicht gegen HyperAlloc-Flow-Interna programmieren	Emvus
`PL-EV-017`	Package-Dichte und Source-Organisation	Emvus
`PL-EV-018`	Sprachnative Regeln schlagen sprachübergreifende Nachahmung	Emvus
`PL-RS-001`	Idiomatische Namen und Sichtbarkeit	Rust
`PL-RS-002`	Guard Clauses und linearer Fluss	Rust
`PL-RS-003`	`Result`, `Option` und `?` bevorzugen	Rust
`PL-RS-004`	`unwrap`, `expect` und `panic!` einschränken	Rust
`PL-RS-005`	`match` und Patterns für echte Zustandsverzweigung	Rust
`PL-RS-006`	Ownership muss bewusst sein	Rust
`PL-RS-007`	Standardmäßig unveränderlich	Rust
`PL-RS-008`	Traits erfordern eine echte Abstraktion	Rust
`PL-RS-009`	Kohäsion vor Größe für `struct`, `impl` und Module	Rust
`PL-RS-010`	Modul- und Dateidichte	Rust
`PL-RS-011`	Rustfmt als Formatierungsautorität	Rust
`PL-RS-012`	Klare Iteration statt cleverer Ketten	Rust
`PL-RS-013`	Async-Tasks haben Ownership und Shutdown	Rust
`PL-RS-014`	Ressourcenlebenszyklen sollen vorhersehbar sein	Rust
`PL-RS-015`	Unsafe-Code isolieren und begründen	Rust
`PL-RS-016`	FFI- und Plattformgrenzen sind explizit	Rust
`PL-RS-017`	Typen bevorzugen, die Invarianten kodieren	Rust
`PL-RS-018`	Macro-Cleverness vermeiden	Rust
`PL-RS-019`	Performance messen, bevor Komplexität entsteht	Rust
`PL-RS-020`	Testing und Tooling	Rust