code-standardslisted

Pragmatic engineering standards for production code: deep modules over micro-functions, review bar that improves code health, ASVS-aligned security checks, naming and error handling, test strategy. Use when writing or reviewing application code, setting a team style, or checking a PR against a shared bar. Prefer trade-offs over Clean Code dogma.
novahiz/novahiz · ★ 1 · AI & Automation · score 70

Install: claude install-skill novahiz/novahiz

# code-standards A shared bar for code that other people will read and change. Optimize for change cost and debuggability. Line counts and rule purity are secondary. ## Review standard (Google eng-practices shape) Approve a change when it improves overall code health, even if it is imperfect. Do not block for weeks chasing polish. Technical facts and the style guide beat personal taste. Blocking: - Makes the system worse (unclear ownership of a bug fix, silent behavior change without tests). - Security or data-loss risk with no mitigation in the PR. - Breaks the agreed style guide where the guide already speaks. Non-blocking (mark as nit): - Naming and formatting the guide does not cover. - “Could be nicer” refactors that belong in a follow-up. - Educational comments that do not change the decision. Escalate when author and reviewer disagree after one round. Do not let a PR idle. ## Design: depth over micro-cuts A module earns its place when a simple interface hides real work (deep module). Splitting every helper into three lines usually creates entanglement: the reader flips between files to understand one path. - Prefer one clear function that does the job over a constellation of one-liners. - Extract when the interface is simpler than the body. A length rule alone is a weak reason. - Duplication that is still evolving may stay until a stable abstraction appears. - Comments explain contracts and non-obvious why. Restating the function name in a comment is noise.