Code style

Pureline

Spec 1.1 47 rules 5 Language profiles

Code without noise.

My own code style. Linear control flow, explicit intent, no unnecessary code — fully documented with stable rule IDs and profiles for Java, JavaScript, TypeScript, Go and Crystal.

Read the specification View language profiles
  • Linear Flow
  • Explicit Intent
  • Minimal Noise
  • Small Units
  • Clear Ownership
PL-CF-001

The difference

The same logic twice. Nested, the happy path keeps drifting to the right — with guard clauses it stays at the base level.

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

The core rules

They apply to every language, as far as the language allows them naturally.

  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
Chapters

The specification

Every chapter with rules, reasoning and code examples — what Pureline is and what it is not.

Fundamentals

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

Architecture & practice

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

One rule set, everywhere

Checker, formatter, CLI and IDE plugins share the same specification. Every diagnostic references a stable rule 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.
How Pureline code should feel
  • 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.