Every rule. One ID.

Stable rule IDs keep the website, checker, CLI, formatter and IDE integrations consistent. 112 rules, 51 of them checkable automatically.

ID	Rule	Profile
`PL-CORE-001`	Control flow should be as linear as possible	Core
`PL-CORE-002`	Avoid else	Core
`PL-CORE-003`	Prefer guard clauses	Core
`PL-CORE-004`	Use the clearest control-flow form for the language; brace-based languages use explicit blocks	Core
`PL-CORE-005`	Idiomatic language-native shorthand is allowed when it remains immediately readable	Core
`PL-CORE-006`	Functions should be small and focused	Core
`PL-CORE-007`	Names must carry meaning	Core
`PL-CORE-008`	Avoid unnecessary abstractions	Core
`PL-CORE-009`	Avoid God Classes and God Modules	Core
`PL-CORE-010`	Prefer immutable state	Core
`PL-CORE-011`	Prefer modern language features where they improve clarity	Core
`PL-CORE-012`	Avoid unnecessary vertical formatting	Core
`PL-CORE-013`	Comments must not compensate for unclear code	Core
`PL-CORE-014`	Handle invalid and error states early	Core
`PL-CORE-015`	Keep important side effects visible	Core
`PL-CORE-016`	Resources must have a clear lifecycle	Core
`PL-CORE-017`	Prefer framework-native APIs	Core
`PL-CORE-018`	Avoid magic values	Core
`PL-CORE-019`	Make dependencies explicit	Core
`PL-CORE-020`	Optimize hot paths deliberately, not accidentally	Core
`PL-CORE-021`	Keep packages and source folders small enough to scan at a glance	Core
`PL-CORE-022`	Cohesion over Size: prefer one coherent responsibility over arbitrary class line limits	Core
`PL-CF-001`	Prefer Guard Clauses	Core
`PL-CF-002`	Avoid else	Core
`PL-CF-003`	Explicit Blocks in Brace-Based Languages	Core
`PL-NAME-001`	Names Must Be Meaningful	Core
`PL-FN-001`	One Clear Responsibility per Function	Core
`PL-STRUCT-001`	One Clear Responsibility per Class and Module	Core
`PL-STRUCT-002`	Keep Namespaces Small Enough to Scan	Core
`PL-STRUCT-003`	Cohesion over Size	Core
`PL-ARCH-001`	Abstraction Requires a Reason	Core
`PL-FMT-001`	Prefer Compact Horizontal Calls	Core
`PL-DOC-001`	Comments Explain Why, Not What	Core
`PL-JAVA-001`	Package by Responsibility	Java
`PL-JAVA-002`	Naming	Java
`PL-JAVA-003`	Prefer Records for Immutable Data	Java
`PL-JAVA-004`	Explicit Null Handling	Java
`PL-JAVA-005`	Use Imports Instead of FQCNs	Java
`PL-JAVA-006`	Prefer Modern Java	Java
`PL-JAVA-007`	Prefer Switch for Real State Branching	Java
`PL-JAVA-008`	Concurrency	Java
`PL-JAVA-009`	Streams Only When Clearer	Java
`PL-JAVA-010`	Lifecycle Symmetry	Java
`PL-JS-001`	Braces Are Mandatory	JavaScript
`PL-JS-002`	Use Semicolons	JavaScript
`PL-JS-003`	`const` First	JavaScript
`PL-JS-004`	Prefer `async` / `await`	JavaScript
`PL-JS-005`	Arrow Functions Are Contextual	JavaScript
`PL-JS-006`	Destructuring Must Improve Clarity	JavaScript
`PL-JS-007`	Folder Density	JavaScript
`PL-TS-001`	Avoid `any`	TypeScript
`PL-TS-002`	Use Types Deliberately	TypeScript
`PL-TS-003`	No Java-Style `I` Prefix	TypeScript
`PL-TS-004`	`interface` vs `type`	TypeScript
`PL-TS-005`	Prefer Union Types Over Enums When Appropriate	TypeScript
`PL-TS-006`	Strong Types at Boundaries, Freedom Internally	TypeScript
`PL-TS-007`	Folder Density	TypeScript
`PL-GO-001`	Error Guards	Go
`PL-GO-002`	Avoid `else` After Terminating Branches	Go
`PL-GO-003`	Idiomatic Naming	Go
`PL-GO-004`	Short Receiver Names Are Allowed	Go
`PL-GO-005`	Small Interfaces	Go
`PL-GO-006`	Define Interfaces Near Consumers	Go
`PL-GO-007`	Use `defer` for Clear Resource Lifecycles	Go
`PL-GO-008`	Goroutines Need Ownership	Go
`PL-GO-009`	Avoid Premature Interface Abstraction	Go
`PL-CR-001`	Idiomatic Postfix Guards Are Allowed	Crystal
`PL-CR-002`	Avoid `else`	Crystal
`PL-CR-003`	Idiomatic Naming	Crystal
`PL-CR-004`	Prefer Type Inference	Crystal
`PL-CR-005`	Explicit Nil Guards	Crystal
`PL-CR-006`	Exceptions Are for Exceptional States	Crystal
`PL-CR-007`	Avoid Macro Cleverness Without Need	Crystal
`PL-CR-008`	Folder Density	Crystal
`PL-EV-001`	Native Method Declarations	Emvus
`PL-EV-002`	Empty Declaration Parentheses Are Optional; Call Parentheses Are Not	Emvus
`PL-EV-003`	Braces Required; Semicolons Optional	Emvus
`PL-EV-004`	Naming, Imports, and Visibility	Emvus
`PL-EV-005`	Types Should Communicate Intent	Emvus
`PL-EV-006`	Handle Nullability Through Stable Flow	Emvus
`PL-EV-007`	Prefer Typed Result Handling for Expected Failures	Emvus
`PL-EV-008`	Make Resource Lifetimes Visible with `scoped`	Emvus
`PL-EV-009`	Prefer Data Classes to Boilerplate	Emvus
`PL-EV-010`	Lists, Tuples, and Dictionaries Retain Their Defined Semantics	Emvus
`PL-EV-011`	Destructuring Is Positional	Emvus
`PL-EV-012`	`switch` Should Expose Complete Branching	Emvus
`PL-EV-013`	Use Cascades Only When They Clarify a Single Receiver	Emvus
`PL-EV-014`	Fibers and Threads Need Clear Lifecycles	Emvus
`PL-EV-015`	Macros Must Improve Discoverability, Not Obscure It	Emvus
`PL-EV-016`	Do Not Program Against HyperAlloc Flow Internals	Emvus
`PL-EV-017`	Package Density and Source Organization	Emvus
`PL-EV-018`	Language-Native Rules Override Cross-Language Imitation	Emvus
`PL-RS-001`	Idiomatic Naming and Visibility	Rust
`PL-RS-002`	Guard Clauses and Linear Flow	Rust
`PL-RS-003`	Prefer `Result`, `Option`, and `?`	Rust
`PL-RS-004`	Restrict `unwrap`, `expect`, and `panic!`	Rust
`PL-RS-005`	Use `match` and Patterns for Real State Branching	Rust
`PL-RS-006`	Ownership Must Be Deliberate	Rust
`PL-RS-007`	Immutable by Default	Rust
`PL-RS-008`	Traits Require a Real Abstraction	Rust
`PL-RS-009`	Cohesion over Size for `struct`, `impl`, and Modules	Rust
`PL-RS-010`	Module and File Density	Rust
`PL-RS-011`	Use Rustfmt as the Formatting Authority	Rust
`PL-RS-012`	Prefer Clear Iteration over Clever Chains	Rust
`PL-RS-013`	Async Tasks Have Ownership and Shutdown	Rust
`PL-RS-014`	Resource Lifecycles Should Be Predictable	Rust
`PL-RS-015`	Unsafe Code Must Be Isolated and Justified	Rust
`PL-RS-016`	FFI and Platform Boundaries Are Explicit	Rust
`PL-RS-017`	Prefer Types that Encode Invariants	Rust
`PL-RS-018`	Avoid Macro Cleverness	Rust
`PL-RS-019`	Measure Performance Before Complexity	Rust
`PL-RS-020`	Testing and Tooling	Rust