Java clean code

Skill nxd1184/java-clean-code-skill/.claude/skills/java-clean-code

Use when writing, reviewing, or refactoring Java code — services, controllers, libraries, batch jobs, CLIs (Spring Boot, Quarkus, plain Java). Triggers: "clean this up", "is this idiomatic?", code review on Java files, code-smell or technical-debt concerns, SOLID/DRY/SRP questions, TDD setup for Java.From its SKILL.md

Install

npx -y skills add nxd1184/java-clean-code-skill --skill java-clean-code

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.1 KB, as published. Nobody here has run it

Java Clean Code

Overview

20 high-ROI rules for Java, with topic references for depth. Same checklist for writing, reviewing, and refactoring.

When to Apply

Writing, reviewing, or refactoring Java classes/methods/endpoints/services; or answering principle questions about Java design.

Skip when: trivial edits, build/config files, non-Java code, or when the user opts out.

The Top 20 Rules

Each rule links to a reference file for depth. A subset keeps a Check hint where the name alone is ambiguous.

Names reveal intent. naming
Functions do one thing. functions
≤3 arguments per function. functions
No flag (boolean) arguments. functions
Command-Query Separation. Method either does OR answers, not both. functions
One abstraction level per function. functions
Stepdown rule (newspaper metaphor). High-level entry points at top, helpers below. formatting
No hidden side effects. functions
Exceptions over error codes. functions
Law of Demeter — no trainwrecks. No a.getB().getC().doD() chains on objects (chains on data structures OK). objects-and-data
Objects hide data; expose behavior. objects-and-data
Single Responsibility Principle. solid
DRY. functions
Consistent vocabulary. naming
Write the test first (TDD). testing
Tests are FIRST. Fast, Independent, Repeatable, Self-validating, Timely. testing
No magic numbers or unexplained literals. naming
Early returns over deep nesting. Max 2 levels of nesting inside a function. functions
Constructor injection (DIP). @Autowired field injection is a smell; inject via final constructor params. solid
Comments earn their keep. Explain WHY, not WHAT. comments

Workflow

Writing: (1) Name the behavior — if you can't, the design isn't ready. (2) Write the failing test (JUnit 5). (3) Implement minimally, rules 2–6 in mind. (4) Self-check with the checklist below.

Reviewing: (1) Cite each violation by rule name (Demeter, SRP, DIP — never bare "R10") + file:line. (2) Prioritize severity — SRP/Demeter/testing gaps outrank naming nits. (3) Diff-style fixes, each naming the rule. (4) Open references/*.md for rationale.

References

Each rule links inline to the topic file. Additional depth: smells, architecture, concurrency, craftsmanship, creating-objects, generics, lambdas-and-streams, exceptions.

Pre-delivery checklist

Verb+noun names; no flags; ≤3 args.
Tests exist, run fast, written first.

Rationalizations

Excuse	Counter
"One more arg"	Args/Flags: extract a `record`.
"Use Lombok `@Data`"	DIP: write the explicit constructor.
"Fine for a demo"	SRP holds under pressure.
"Review with bare numbers (R10)"	Cite the rule name + `references/*.md`.

Violating the letter of a rule is violating its spirit. Pressure (time, demo, sunk cost) does not suspend the rules — it makes them more valuable.