2.3 KiB
2.3 KiB
Philosophy of Software Design — Codex Skill
Goal
Design software so it is easy to understand, change, and extend.
Core rule
Optimize for lower complexity, not just fewer lines of code.
Recommendations
- Prefer deep modules. Hide substantial complexity behind a small, clean interface.
- Keep interfaces simple. Expose only what callers truly need.
- Hide information aggressively. Do not leak implementation details across module boundaries.
- Do not pass complexity around. Solve it where it belongs instead of pushing it onto callers.
- Make the important things obvious. Favor clarity over cleverness.
- Minimize special cases. Exceptions, one-off rules, and edge-paths increase cognitive load.
- Design invalid states out of the system. Prevent mistakes through better APIs and structure.
- Separate mechanism from policy. Keep reusable machinery distinct from usage-specific decisions.
- Use precise names. Good naming reduces system-wide confusion.
- Write comments that add information. Explain why, constraints, invariants, and intent — not what the code already says.
- Document interfaces clearly. State guarantees, expectations, and failure modes.
- Refactor early when complexity starts rising. Small structural fixes compound.
- Be consistent. Similar things should look and behave similarly.
- Protect layering. Higher-level code should not depend on unnecessary low-level details.
- Write for future readers. Assume the next editor needs the system to be legible fast.
Decision filter
Before adding code, ask:
- Does this reduce or increase cognitive load?
- Does this make future changes easier?
- Is the interface smaller and clearer?
- Am I hiding complexity or spreading it?
- Will another engineer understand this quickly?
Anti-patterns
Avoid:
- clever abstractions with leaky interfaces
- shallow modules that add indirection without hiding complexity
- comments that merely restate code
- special cases added without simplifying the general model
- dependency tangles across layers
Output standard
When generating or editing code:
- favor simple, stable interfaces
- keep module responsibilities crisp
- eliminate unnecessary branching and exceptions
- choose clarity over brevity when they conflict
- leave the codebase easier to change than before