java-conventions

Name: java-conventions
Author: AdamBien

40stars10forks

How to install java-conventions?

adambien/airails/java-conventions

$npx -y skills add AdamBien/airails --skill java-conventions

Installs into the current project.

Summary

Generic, composable Java 25 code conventions — modern syntax, code style, naming, visibility, structure, methods, streams, exceptions, and documentation rules that apply across all Java contexts (single-file scripts, CLI apps, MicroProfile/Jakarta EE servers, libraries). Technolo

Files · 1

View on GitHub

SKILL.md

1	## Scope
2
3	- Language-level rules for Java 25 only — syntax, style, naming, visibility, structure, methods, streams, exceptions, comments.
4	- Architecture (BCE, layering, packaging) is not in this skill — see `bce`.
5	- Build, packaging, framework, and protocol rules are not in this skill — see `java-cli-script`, `java-cli-app`, `microprofile-server`, `zb`, etc.
6	- When a composed skill specifies a rule, the composed skill wins; this skill is the fallback baseline.
7
8	## Java Version & Syntax
9
10	- target Java 25; assume all features are GA — never use `--enable-preview`
11	- use modern syntax naturally: `var`, records, sealed types, pattern matching, text blocks, switch expressions
12	- use `var` for local variable declarations where the type is obvious from the right-hand side
13	- use module imports (e.g. `import module java.net.http;`) over individual type imports
14	- do not import packages from `java.base` — it is automatically available
15	- use switch expressions with arrow syntax (`case X -> ...`) over old `case X:` statements with `break`
16	- use pattern matching for `instanceof` — `if (o instanceof String s)` over cast-and-assign
17	- use pattern matching in `switch` for type-based dispatch
18	- use the diamond operator `<>` for generic type inference
19	- never use raw generic types — always parameterize
20	- prefer `void main()` / `void main(String... args)` over `public static void main(String[] args)`; instance main, not static
21
22	## Java SE APIs
23
24	- use Java SE APIs over writing custom code — the standard library has it, usually in `java.util`, `java.nio.file`, `java.net.http`, or `java.time`
25	- prefer the most specific Java SE type for the domain — `Path` over `String`, `URI` over `String`, `Duration` over `long millis`, `Instant`/`LocalDate` over `Date`/`long`
26
27	## Visibility & Modifiers
28
29	- avoid `private` methods (including `private static` helpers) — prefer package-private (default) so same-package unit tests can exercise them directly, including edge cases, without round-tripping through the public API
30	- avoid `private` fields — prefer package-private so same-package tests can read or seed state without reflection or extra accessors
31	- reserve `private` for genuinely sensitive state (credentials, security tokens, invariants that must never be observed externally); the burden of justification is on `private`, not on package-private
32	- do not use `final` on fields — exception: `static final` for constants like `LOGGER`
33	- do not use `final` on local variables or parameters
34	- do not use constructor injection — prefer field injection in CDI contexts
35	- avoid mutable static fields
36
37	## Interfaces & Classes
38
39	- only use interfaces with multiple implementations or for the strategy pattern; never create an interface whose only purpose is to be implemented by one class
40	- for stateless or procedural logic, prefer interfaces with `static` methods over classes with private constructors
41	- in utility interfaces, prefer `static` over `default` methods
42	- avoid anonymous inner classes — extract them into named, testable top-level classes (e.g. a CDI bean produced via `@Produces`) instead of instantiating an interface inline
43	- use records by default for value types and data carriers
44	- use sealed interfaces or sealed classes for closed type hierarchies (pairs well with pattern matching)
45	- prefer factory methods (static `of`, `from`, etc.) in records over passing `null` to constructors
46	- prefer composition over inheritance
47	- create multiple classes only if it decreases complexity and increases readability
48
49	## Naming
50
51	- name classes, modules, and files after their responsibilities, not technical concerns
52	- avoid meaningless suffixes: `Impl`, `Service`, `Manager`, `Creator`
53	- class names must not end with `Control`
54	- reserve protocol- or pattern-specific suffixes for elements that actually fulfill that role: `Resource` for JAX-RS classes, `Factory` for actual GoF factories, `Builder` for classes with method chaining
55	- avoid the `get` prefix; use the record-style convention — `configuration()` not `getConfiguration()`
56
57	## Methods & Lambdas
58
59	- keep methods short, cohesive, and testable
60	- create well-named methods for coarse-grained, self-contained logic
61	- ne

People who liked this also viewed

6 picks

Type

java-conventions

40stars10forks

View on GitHub

How to install java-conventions?

adambien/airails/java-conventions

$npx -y skills add AdamBien/airails --skill java-conventions

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Scope
2
3	- Language-level rules for Java 25 only — syntax, style, naming, visibility, structure, methods, streams, exceptions, comments.
4	- Architecture (BCE, layering, packaging) is not in this skill — see `bce`.
5	- Build, packaging, framework, and protocol rules are not in this skill — see `java-cli-script`, `java-cli-app`, `microprofile-server`, `zb`, etc.
6	- When a composed skill specifies a rule, the composed skill wins; this skill is the fallback baseline.
7
8	## Java Version & Syntax
9
10	- target Java 25; assume all features are GA — never use `--enable-preview`
11	- use modern syntax naturally: `var`, records, sealed types, pattern matching, text blocks, switch expressions
12	- use `var` for local variable declarations where the type is obvious from the right-hand side
13	- use module imports (e.g. `import module java.net.http;`) over individual type imports
14	- do not import packages from `java.base` — it is automatically available
15	- use switch expressions with arrow syntax (`case X -> ...`) over old `case X:` statements with `break`
16	- use pattern matching for `instanceof` — `if (o instanceof String s)` over cast-and-assign
17	- use pattern matching in `switch` for type-based dispatch
18	- use the diamond operator `<>` for generic type inference
19	- never use raw generic types — always parameterize
20	- prefer `void main()` / `void main(String... args)` over `public static void main(String[] args)`; instance main, not static
21
22	## Java SE APIs
23
24	- use Java SE APIs over writing custom code — the standard library has it, usually in `java.util`, `java.nio.file`, `java.net.http`, or `java.time`
25	- prefer the most specific Java SE type for the domain — `Path` over `String`, `URI` over `String`, `Duration` over `long millis`, `Instant`/`LocalDate` over `Date`/`long`
26
27	## Visibility & Modifiers
28
29	- avoid `private` methods (including `private static` helpers) — prefer package-private (default) so same-package unit tests can exercise them directly, including edge cases, without round-tripping through the public API
30	- avoid `private` fields — prefer package-private so same-package tests can read or seed state without reflection or extra accessors
31	- reserve `private` for genuinely sensitive state (credentials, security tokens, invariants that must never be observed externally); the burden of justification is on `private`, not on package-private
32	- do not use `final` on fields — exception: `static final` for constants like `LOGGER`
33	- do not use `final` on local variables or parameters
34	- do not use constructor injection — prefer field injection in CDI contexts
35	- avoid mutable static fields
36
37	## Interfaces & Classes
38
39	- only use interfaces with multiple implementations or for the strategy pattern; never create an interface whose only purpose is to be implemented by one class
40	- for stateless or procedural logic, prefer interfaces with `static` methods over classes with private constructors
41	- in utility interfaces, prefer `static` over `default` methods
42	- avoid anonymous inner classes — extract them into named, testable top-level classes (e.g. a CDI bean produced via `@Produces`) instead of instantiating an interface inline
43	- use records by default for value types and data carriers
44	- use sealed interfaces or sealed classes for closed type hierarchies (pairs well with pattern matching)
45	- prefer factory methods (static `of`, `from`, etc.) in records over passing `null` to constructors
46	- prefer composition over inheritance
47	- create multiple classes only if it decreases complexity and increases readability
48
49	## Naming
50
51	- name classes, modules, and files after their responsibilities, not technical concerns
52	- avoid meaningless suffixes: `Impl`, `Service`, `Manager`, `Creator`
53	- class names must not end with `Control`
54	- reserve protocol- or pattern-specific suffixes for elements that actually fulfill that role: `Resource` for JAX-RS classes, `Factory` for actual GoF factories, `Builder` for classes with method chaining
55	- avoid the `get` prefix; use the record-style convention — `configuration()` not `getConfiguration()`
56
57	## Methods & Lambdas
58
59	- keep methods short, cohesive, and testable
60	- create well-named methods for coarse-grained, self-contained logic
61	- ne

People who liked this also viewed

6 picks

Type