菜单
Naming decisions for variables, functions, classes, constants, and APIs. Use when choosing names, reviewing naming quality, refactoring unclear names, or establishing naming conventions. Covers descriptive naming, naming as documentation, language-specific conventions, and common naming antipatterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Antipattern catalog with categorized patterns, symptoms, examples, and fixes. Use when reviewing code for quality issues, detecting bad patterns during plan-audit or scope, evaluating whether a pattern is an antipattern or acceptable tradeoff, or fixing existing code smells. Covers surprise, misuse, complexity, and premature antipattern categories with severity classification.
Plan quality auditing with completeness scorecard, antipattern risk detection, and readiness checks. Use when auditing implementation plans, evaluating plan completeness, checking error handling strategy, assessing naming and readability pre-checks, reviewing testing strategy, evaluating tradeoff documentation, or running plan-audit on a software project. Covers the 10-point completeness scorecard, code quality pre-checks, antipattern risk assessment, and build-readiness decision.
Dead code detection strategies, safe removal processes, dependency pruning, and bloat metrics for systematically reducing codebase dead weight. Use when evaluating codebase health during architecture-audit, performing cleanup during cook, reviewing unused dependencies, removing commented-out code, or measuring code bloat.
Code quality pillars, goals, abstraction layers, and tradeoff thinking. Use when evaluating code quality, setting quality goals, choosing abstraction levels, making design tradeoffs, or auditing code against quality pillars. Covers readability, modularity, testability, reusability, and the principle of least astonishment.
Code readability patterns covering comments, function decomposition, nesting, naming conventions, and code structure. Use when evaluating whether code is easy to understand, deciding when and how to write comments, decomposing functions, reducing nesting depth, improving code structure, or reviewing code for readability. Covers comment strategy, function length, abstraction level mixing, nesting reduction, anonymous function readability, and making bad code visually obvious.
Code review process, effective feedback, PR best practices, team working agreements, review automation, AI-augmented review, and review antipatterns. Use when reviewing code, preparing PRs, giving review feedback, setting up review processes, writing review comments, or conducting code reviews during serve phase.
| name | code-naming |
| description | Naming decisions for variables, functions, classes, constants, and APIs. Use when choosing names, reviewing naming quality, refactoring unclear names, or establishing naming conventions. Covers descriptive naming, naming as documentation, language-specific conventions, and common naming antipatterns. |
| You're naming a... | It should read like... | Form | Examples |
|---|---|---|---|
| Class / Type | A noun or noun phrase | PascalCase (most langs) | UserProfile, HttpClient, InvoiceParser |
| Function / Method | A verb or verb phrase | camelCase or snake_case | validateEmail, send_invoice, calculateTotal |
| Boolean | A yes/no question | is/has/can/should prefix | isActive, hasPermission, canRetry |
| Collection | A plural noun | Plural form | users, pendingOrders, activeConnections |
| Constant | A named fact | UPPER_SNAKE_CASE (most langs) | MAX_RETRY_COUNT, DEFAULT_TIMEOUT_MS |
| Interface | A capability or contract | Language-specific | Serializable, IDisposable, Reader |
| Enum | A set of named options | PascalCase values | Color.Red, RetryPolicy.ALLOW_RETRY |
| Event / Callback | What happened or will happen | Past/present tense | onClick, onUserCreated, handleSubmit |
Before committing to a name, verify it answers all three:
If a name requires a comment to be understood, the name is wrong.
| Antipattern | Problem | Fix |
|---|---|---|
accountList when it's a Set | Wrong data structure in name | accounts (just use plural) |
processData_v2 | Version control in names | Use version control, not naming |
getUser() that also logs and caches | Name doesn't reveal side effects | fetchAndCacheUser() or split |
isEnabled that modifies state | Query name hides a command | Separate query from mutation |
| Antipattern | Problem | Fix |
|---|---|---|
data, info, item, thing | Generic to the point of meaningless | Use domain-specific terms |
tmp, val, x beyond tiny scope | Forces reader to track mentally | currentTemperature, retryCount |
manager, handler, processor | Vague role descriptions | Describe what it manages |
utils, helpers, misc | Grab-bag namespaces | Group by domain or operation |
| Antipattern | Problem | Fix |
|---|---|---|
| Inconsistent casing | Readers assume variables are lowercase | Follow language conventions exactly |
Abbreviations (usrRepo, passwd) | Ambiguous unless universally known | Spell it out: userRepository, password |
Noise words (UserData vs UserInfo) | Indistinguishable without reading code | Pick one and be consistent |
Negated booleans (isNotActive) | Double negatives in conditions | Use positive: isActive |
| Antipattern | Problem | Fix |
|---|---|---|
Hungarian notation (strName, iCount) | Type system already encodes types | Just name, count |
Gratuitous prefix (GSDAccountService) | Every class in app has same prefix | Use namespaces/packages |
AbstractBase + Impl suffix | Naming the pattern not the concept | UserService + DefaultUserService |
URL, HTTP, API)