code-standard · git:20261029.be105a9 · 2026-10-29 · sha256 178402ada1f6563c

code-standard git:20261029.be105a9A

Immutable. This exact content never changes and is served at /api/v1/blob/178402ada1f6563c.

---
name: code-standard
title: 代码规范
summary: 每次写、改、审代码都遵循:去掉冗余、降低复杂度、提高可读性和可维护性,行为和接口保持不变。分阶段改、用现有测试验证,最后总结删了什么、简化了什么、还剩什么问题。
description: Apply this code standard whenever writing, refactoring or reviewing code to reduce redundancy and complexity, improve readability and maintainability, and preserve behavior and interfaces.
---

# Code standard

Goal: less redundant code, lower cognitive complexity, better readability, maintainability and execution efficiency.

The project's own conventions and linters take precedence where they differ.

## Rules

1. **No redundant code.** Remove duplicated logic, pointless intermediate variables, needless wrapper functions and
   boilerplate.
2. **Simple control flow.** Avoid redundant if/else, deep nesting and tangled branches; use early returns and pattern
   matching where they make the code clearer.
3. **Concise code.** Shorten verbose expressions and functions, but never at the cost of readability.
4. **Clear structure.** Split functions and modules whose responsibility is unclear; extract only logic that is
   really reused; no over-abstraction.
5. **Readability.** Consistent naming and formatting; comment complex business logic (why, not what); delete
   meaningless comments. Match the surrounding code's style and comment density.
6. **No code smells.** Fix duplicated code, overlong functions, oversized modules, over-design and unnecessary
   dependencies.

## Principles

- Keep existing behaviour, external interfaces and expected results unchanged.
- Do not trade clarity for fewer lines.
- Add no unnecessary abstractions, design patterns or new dependencies.
- Prefer the language's idiomatic way of doing things.
- Change in stages and verify each stage with the existing tests.
- Finish with a summary: redundancy removed, complexity reduced, problems left.

## For the lead

When work is split across workers (see the model-routing skill), include these rules in every worker brief. The lead
reviews each returned diff against them before accepting it and sends violations back with the specific lines.