Clean Code (1)

**Judgement:** A strong, opinionated clean-code standard that works especially well for TypeScript/JavaScript and generally for modern, statically typed codebases. It’s well-suited for scenarios where you want the assistant to enforce clear, consistent, and relatively strict readability and structure conventions. **Strengths:** - Covers key aspects of maintainable code: naming, function design, structure, anti-patterns, and pre-edit checklists. - Provides concrete rules and examples (guard clauses, discriminated unions, composition over god functions) that an assistant can apply systematically. - Checklists for dependencies and tests help reduce accidental breakage during refactors. **Risks / Limitations:** - Rules are dogmatic in places (e.g., “NEVER write functions longer than 20 lines”, “NEVER nest deeper than 2 levels”), which can be inappropriate for legacy code, performance-critical sections, or frameworks that favor certain patterns. - Examples and guidance are biased toward TypeScript/JS; mapping to other paradigms (low-level C, highly functional code, or framework-driven architectures) may require adaptation. - Strict adherence could sometimes over-prioritize stylistic consistency over domain constraints or existing project conventions. **Recommended Scenarios:** - Use as the default guideline when asking the assistant to **review or refactor code for cleanliness, readability, and maintainability**. - Apply when **setting or documenting coding standards** for a project that values clarity and small, focused functions. - Use as a **refactoring aid** when breaking down god functions, flattening deep nesting, and eliminating magic numbers or junk-drawer utils. - Prefer a softer or customized approach when working in **heavily constrained legacy systems**, performance-critical hotspots, or when the project already has strong, differing conventions.