Book Code Complete Nano

---
name: book--code-complete--nano
description: >-
  Code Complete (Steve McConnell) — Minimal rules — essential one-liners only. Use when asked to apply Code Complete principles or review code against Code Complete standards.
origin: "github.com/ciembor/agent-rules-books (MIT)"
license: MIT
version: "1.0.0"
compatibility: "yana-ai >= 0.14.0"
---

# OBEY Code Complete by Steve McConnell

## When to use

Use as a compact always-on construction discipline for implementation, review, debugging, refactoring, and tuning.

## Primary bias to correct

Working code is not enough. Construction must lower defect risk, control complexity, and make human inspection cheap.

## Decision rules

- Clarify requirements, architecture fit, risks, conventions, and major construction decisions before coding from a solution idea.
- Choose clarity, locality, explicitness, simple control flow, and consistent style over clever compactness or fashionable idioms.
- Keep routines, classes, and modules cohesive, precisely named, small at the interface, encapsulated, and hard to misuse.
- Make data meaning visible with names, constants, stronger types, closed states, deliberate initialization, units, and ownership.
- Validate trust boundaries; use assertions, invariants, and contracts for programmer assumptions; keep error handling explicit and diagnosable.
- Keep branches, loops, exits, exceptions, and table-driven logic simple enough to verify.
- Build, test, review, debug, refactor, integrate, and tune in small evidence-based loops: root cause before fixes, behavior protection before refactoring, measurement before optimization.
- Use comments, documentation, tools, and standards to reduce reader or manual effort, never to hide poor structure.

## Trigger rules

- When a solution appears before the problem is clear, restate the requirement, constraints, and construction risks.
- When readers must decode names, flags, primitives, units, states, or layout, model the meaning explicitly.
- When a routine mixes phases or has a hard-to-use interface, split concerns or change the data model.
- When input crosses a trust boundary, decide validation, rejection, recovery, assertion, and diagnostics.
- When control flow, loops, exceptions, or branching tables are hard to inspect, simplify before adding logic.
- When tests only prove happy paths, add boundary, invalid-input, defensive-check, contract, and data-driven cases.
- When debugging, refactoring, or performance work starts from a guess, get evidence first.
- When comments repeat obvious mechanics, rewrite the code or delete the comment; keep comments for intent and constraints.

## Final checklist

- Clear construction context?
- Inspectable code shape?
- Explicit data meaning?
- Defended boundaries and diagnosable failures?
- Simple flow?
- Defect-finding tests and reviews?
- Evidence before fixes, refactors, and tuning?