The Agent Skills Directory
npx skills add https://smithery.ai/skills/obra/domain-focused-naming记录实现细节或历史背景的命名会造成混淆。"NewUserAPI" 没有说明它做什么。"ZodValidator" 暴露了内部实现。
核心原则: 命名应说明代码在领域中的功能,而不是它如何构建或替换了什么。
违反这条规则的文字表述,就是违反命名的精神。
适用于:
特别适用于:
命名暴露的是"做什么",而不是"怎么做"。
代码存在于当下。不要引用过去或过渡状态。
模式是实现细节。大多数模式无助于理解。
// 当模式本身就是目的时,可以使用
class EventEmitter { } // 观察者模式就是它的功能
class CommandQueue { } // 队列模式就是它的功能
好的命名能构成关于业务逻辑的句子。
// 读起来像领域语言
user.authenticate()
order.calculateTotal()
payment.process()
// 不要这样
user.executeAuthenticationStrategy()
order.runTotalCalculationAlgorithm()
payment.invokeProcessingWorkflow()
| 不良模式 | 为何不良 | 良好替代方案 |
|---|---|---|
ZodValidator | 暴露实现细节 | Validator |
MCPToolWrapper | 暴露协议细节 | RemoteTool |
NewUserAPI | 时间引用 | UserAPI |
ImprovedParser |
规则: 绝不在名称中记录旧行为或变更。
如果你发现自己写了:
立即停止。找一个描述领域中实际用途的名称。
| 借口 | 现实 |
|---|---|
| "需要与旧版本区分" | 旧版本不应存在,或应放在不同的命名空间中。 |
| "新开发者需要知道这是改进版" | 代码质量体现在行为上,而不是名称中。 |
| "工厂模式在这里很重要" | 如果模式是核心目的,可以使用。但通常不是。 |
| "大家都知道 Zod 是什么" | 今天他们知道。但命名应该比依赖项更持久。 |
| "它确实是 MCP 的包装器" | 那是实现细节。它在你的领域中做什么? |
在提交命名前检查:
class ImprovedZodConfigValidator { } // ❌ 时间性 + 实现细节
const newAPIClientWithRetry = new Client(); // ❌ 时间性 + 实现细节
function executeEnhancedToolFactory() { } // ❌ 时间性 + 模式噪音
// 使用它们
const validator = new ImprovedZodConfigValidator();
validator.validateWithNewSchema();
class ConfigValidator { } // ✅ 领域目的
const apiClient = new Client(); // ✅ 它是什么
function createTool() { } // ✅ 它做什么
// 使用它们 - 读起来像领域语言
const validator = new ConfigValidator();
validator.validate();
关于战术性变量命名: 请参阅 skills/naming-variables 了解全面的变量命名技巧(最佳长度、作用域规则、布尔值/集合/限定词的约定、命名作为诊断工具)
关于注释指南: 请参阅 skills/writing-evergreen-comments 了解如何保持注释常青(注释中也不要使用时间上下文)
每周安装次数
–
来源
首次出现
–
Names documenting implementation or history create confusion. "NewUserAPI" doesn't tell what it does. "ZodValidator" exposes internals.
Core principle: Names tell what code does in the domain, not how it's built or what it replaced.
Violating the letter of this rule is violating the spirit of naming.
Use for:
Use ESPECIALLY when:
Names expose WHAT, not HOW.
Code exists in present. Don't reference past or transitions.
Patterns are implementation details. Most don't help understanding.
// OK when pattern IS the purpose class EventEmitter { } // Observer pattern IS what it does class CommandQueue { } // Queue pattern IS what it does
</Good>
### Names Tell Domain Stories
Good names form sentences about business logic.
<Good>
```typescript
// Reads like domain language
user.authenticate()
order.calculateTotal()
payment.process()
// Not
user.executeAuthenticationStrategy()
order.runTotalCalculationAlgorithm()
payment.invokeProcessingWorkflow()
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 引用历史 |
Parser |
ToolFactory | 模式名称噪音 | Tool 或 createTool() |
AbstractToolInterface | 冗余限定词 | Tool |
executeToolWithValidation() | 实现细节在名称中 | execute() |
| Bad Pattern | Why Bad | Good Alternative |
|---|---|---|
ZodValidator | Exposes implementation | Validator |
MCPToolWrapper | Exposes protocol | RemoteTool |
NewUserAPI | Temporal reference | UserAPI |
ImprovedParser | References history | Parser |
ToolFactory | Pattern name noise | Tool or createTool() |
AbstractToolInterface | Redundant qualifiers | Tool |
executeToolWithValidation() | Implementation in name | execute() |
Rule: Never document old behavior or the change in names.
If you catch yourself writing:
STOP. Find a name describing actual purpose in the domain.
| Excuse | Reality |
|---|---|
| "Need to distinguish from old version" | Old version shouldn't exist or should be in different namespace. |
| "New developers need to know it's improved" | Code quality shows in behavior, not names. |
| "Factory pattern is important here" | If pattern is core purpose, fine. Usually it's not. |
| "Everyone knows what Zod is" | Today they do. Names should outlive dependencies. |
| "It IS a wrapper around MCP" | That's implementation. What does it DO in your domain? |
Before committing names:
class ImprovedZodConfigValidator { } // ❌ Temporal + implementation
const newAPIClientWithRetry = new Client(); // ❌ Temporal + implementation
function executeEnhancedToolFactory() { } // ❌ Temporal + pattern noise
// Using them
const validator = new ImprovedZodConfigValidator();
validator.validateWithNewSchema();
class ConfigValidator { } // ✅ Domain purpose
const apiClient = new Client(); // ✅ What it is
function createTool() { } // ✅ What it does
// Using them - reads like domain language
const validator = new ConfigValidator();
validator.validate();
For tactical variable naming: See skills/naming-variables for comprehensive variable naming techniques (optimal length, scope rules, conventions for booleans/collections/qualifiers, naming as diagnostic tool)
For comment guidelines: See skills/writing-evergreen-comments for keeping comments evergreen (no temporal context in comments either)
Weekly Installs
–
Source
First Seen
–
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
109,600 周安装