Code Style

Pureline

Spec 1.1 47 Regeln 5 Sprachprofile

Code without noise.

Mein eigener Code Style. Linearer Kontrollfluss, klare Absicht, kein unnötiger Code — komplett dokumentiert mit stabilen Regel-IDs und Profilen für Java, JavaScript, TypeScript, Go und Crystal.

Die Spezifikation steht im englischen Original.

Spezifikation lesen Sprachprofile ansehen
  • Linear Flow
  • Explicit Intent
  • Minimal Noise
  • Small Units
  • Clear Ownership
PL-CF-001

Der Unterschied

Dieselbe Logik zweimal. Verschachtelt rutscht der Happy Path immer weiter nach rechts — mit Guard Clauses bleibt er auf der Grundebene.

Avoid java 
if (request != null) {
    if (request.valid()) {
        var session = sessions.create(request.user());
        return executor.execute(session, request);
    } else {
        return Result.invalid();
    }
}

return Result.empty();
Preferred java 
if (request == null) {
    return Result.empty();
}

if (!request.valid()) {
    return Result.invalid();
}

var session = sessions.create(request.user());
return executor.execute(session, request);
Pureline Core

Die Core-Regeln

Gelten für jede Sprache, soweit die Sprache sie natürlich zulässt.

  1. PL-CORE-001 Control flow should be as linear as possible
  2. PL-CORE-002 Avoid else
  3. PL-CORE-003 Prefer guard clauses
  4. PL-CORE-004 Use the clearest control-flow form for the language; brace-based languages use explicit blocks
  5. PL-CORE-005 Idiomatic language-native shorthand is allowed when it remains immediately readable
  6. PL-CORE-006 Functions should be small and focused
  7. PL-CORE-007 Names must carry meaning
  8. PL-CORE-008 Avoid unnecessary abstractions
  9. PL-CORE-009 Avoid God Classes and God Modules
  10. PL-CORE-010 Prefer immutable state
  11. PL-CORE-011 Prefer modern language features where they improve clarity
  12. PL-CORE-012 Avoid unnecessary vertical formatting
  13. PL-CORE-013 Comments must not compensate for unclear code
  14. PL-CORE-014 Handle invalid and error states early
  15. PL-CORE-015 Keep important side effects visible
  16. PL-CORE-016 Resources must have a clear lifecycle
  17. PL-CORE-017 Prefer framework-native APIs
  18. PL-CORE-018 Avoid magic values
  19. PL-CORE-019 Make dependencies explicit
  20. PL-CORE-020 Optimize hot paths deliberately, not accidentally
Kapitel

Die Spezifikation

Jedes Kapitel mit Regeln, Begründung und Codebeispielen — was Pureline ist und was nicht.

Grundlagen

2 Control Flow PL-CF-001 PL-CF-002 PL-CF-003 3 Naming PL-NAME-001 4 Functions PL-FN-001 5 Classes and Modules PL-STRUCT-001 6 Formatting PL-FMT-001 7 Comments PL-DOC-001

Architektur & Praxis

13 Abstraction Rules PL-ARCH-001 14 Architecture Pureline prefers clear dependency direction. 15 Side Effects Important side effects should remain visible. 16 Immutability Prefer immutable values by default. 17 Dependencies Dependencies should be visible in constructors, function parameters, or explicit module wi … 18 Performance Pureline prioritizes readability by default, but performance-sensitive paths should be wri …
Tooling

Ein Regelwerk, überall

Checker, Formatter, CLI und IDE-Plugins teilen sich dieselbe Spezifikation. Jede Diagnose verweist auf eine stabile Regel-ID.

  • Pureline Checker
  • Pureline Formatter
  • Pureline CLI
  • IntelliJ Plugin
  • VS Code Extension
  • Eclipse Plugin
  • future IDE integrations
pureline check 
PL-CF-002
Avoid else after a terminating branch.

Line 48:
} else {

Suggested fix:
Remove the else block and continue with the happy path.
So soll sich Pureline-Code anfühlen
  • linear
  • explicit
  • compact
  • modern
  • low-noise
  • modular
  • predictable
  • easy to scan
  • easy to refactor
  • hard to misunderstand
Code without noise.
Pureline standardizes principles, not syntax.