Java Coding Style

Apply these rules when editing Java syntax, class structure, and everyday code organization.

Match the project's Java release, style, and framework conventions. Use newer syntax only when supported and clearer.
Prefer direct control flow and descriptive domain names. Use streams when they clarify a transformation; loops are often clearer for stateful work or error handling.
Use local var only when the initializer makes the type obvious. Keep public contracts explicitly typed.
Use records for transparent immutable carriers and sealed types for genuinely closed variants when the target release supports them. Do not force them onto mutable entities or framework-managed types.
Prefer composition and focused classes over inheritance, reflection, global mutable state, or speculative interfaces.
Make ownership, mutation, and side effects visible. Use final where it clarifies invariants; do not add it mechanically to every local variable.
Prefer supported java.time APIs and standard library facilities over obsolete APIs or custom helpers when they fit the contract.
Remove dead code. Add comments only for non-obvious decisions or public contracts that code cannot express clearly.