命名熔炉

计算机科学中只有两件难事：缓存失效和命名。 — 菲尔·卡尔顿

它的作用

你需要为一个函数命名。它接收一个订单列表，过滤掉已取消的订单，按客户分组，并返回总计。你盯着光标。processOrders？太模糊。filterAndGroupAndSummarizeOrdersByCustomerExcludingCancelled？太长。getOrderSummary？有误导性——它做的不仅仅是获取。

命名熔炉生成的名称精确（说明其功能）、一致（符合代码库的约定）、可发现（其他开发者能猜到搜索什么）且比例恰当（名称长度与作用域重要性匹配）。

好名称的五条法则

法则一：名称应是一份契约

差： updateUser() — 它更新数据库？UI？两者都更新？更新哪些字段？
好： saveUserProfile() — 保存用户资料（到持久化存储）
好： refreshUserDisplay() — 更新用户在屏幕上看到的内容

法则二：作用域决定长度

法则三：动词用于动作，名词用于事物

函数（动词优先）：
├── get/fetch/load → 检索数据（getSessions, fetchUser, loadConfig）
├── set/update/save → 修改数据（setTheme, updateProfile, saveOrder）
├── create/build/make → 构建新事物（createUser, buildQuery, makeHandler）
├── delete/remove → 消除事物（deleteAccount, removeItem）
├── is/has/can/should → 返回布尔值（isValid, hasPermission, canEdit）
├── parse/format/transform → 格式间转换（parseJSON, formatDate）
├── validate/check/verify → 确认正确性（validateEmail, checkStatus）
└── handle/process/on → 响应事件（handleClick, processPayment, onSubmit）

变量（名词/形容词）：
├── 集合：复数名词（users, orders, activeConnections）
├── 单个：单数名词（user, order, currentConnection）
├── 布尔值：is/has/can前缀（isLoading, hasErrors, canSubmit）
├── 计数：名词 + Count（retryCount, errorCount, userCount）
└── 映射/索引：名词 + By + 键（userById, ordersByDate）

法则四：一致性胜过巧妙

代码库审计：
├── 现有模式：fetch*用于API调用 → 使用fetchOrders，不要用getOrders
├── 现有模式：*Service用于模块 → 使用PaymentService，不要用PaymentManager
├── 现有模式：on*用于处理器 → 使用onSubmit，不要用handleSubmit
└── 现有模式：is*用于布尔值 → 使用isActive，不要用active或checkActive

法则五：避免语义噪音

差： userData, userInfo, userObject → 直接用user
差： orderItem → 直接用order（除非需要与订单摘要区分）
差： StringHelper, DateUtils → 它们实际做什么？要具体。
好： formatDate, parseCSV, slugify → 具体动作

熔炼过程

输入：这个东西做什么？（自然语言描述）
上下文：它在代码库的哪个部分？

阶段一：语义提取
├── 从描述中提取核心动作或概念
├── 识别：这是函数、变量、类型、文件还是路由？
├── 识别：作用域是什么？（局部、模块、公共、全局）
└── 识别：适用的领域词汇有哪些？（业务术语、技术术语）

阶段二：约定扫描
├── 扫描现有代码库的命名模式：
│ ├── 动词偏好（get vs. fetch vs. load vs. retrieve）
│ ├── 名词偏好（User vs. Account vs. Profile）
│ ├── 大小写约定（camelCase, snake_case, PascalCase, kebab-case）
│ ├── 前缀/后缀模式（is, Service, Controller, I用于接口）
│ └── 已使用的领域词汇
├── 识别此类名称的主导约定
└── 标记任何现有的不一致

阶段三：候选生成
├── 按照约定生成3-5个候选
├── 对每个候选进行评估：
│ ├── 精确性：名称是否准确描述了事物？
│ ├── 一致性：是否匹配现有模式？
│ ├── 可发现性：队友能猜到这个名字吗？
│ ├── 比例性：长度是否适合作用域？
│ └── 唯一性：是否与任何现有名称冲突？
├── 按综合评分对候选排序
└── 标记候选之间的权衡

阶段四：推荐
├── 最佳推荐及理由
├── 备选方案
├── 应避免的名称（及原因）
└── 如果重命名：迁移影响（需要更新多少引用）

领域特定命名

API路由/端点

模式：/资源/动作 或 RESTful约定

好：
├── GET /users → 列出用户
├── GET /users/:id → 获取特定用户
├── POST /users → 创建用户
├── PUT /users/:id → 替换用户
├── PATCH /users/:id → 部分更新
├── DELETE /users/:id → 删除用户
├── POST /users/:id/verify → 对用户执行动作（动词作为子资源）

差：
├── GET /getUsers → 路径中包含动词（GET已隐含获取）
├── POST /createNewUser → 冗余（POST已隐含创建）
├── GET /user_list → 大小写不一致，使用/users
└── POST /doUserVerification → 过于冗长，使用/users/:id/verify

数据库表/列

表：
├── 复数名词：users, orders, payments（不是user, order, payment）
├── 连接表：userroles, orderitems（按字母顺序或父_子）
├── 一致的大小写：SQL用snake_case，NoSQL用camelCase（匹配ORM）

列：
├── 外键：userid, orderid（表单数 + _id）
├── 布尔值：isactive, hasverified, can_edit（用状态动词前缀）
├── 时间戳：createdat, updatedat, deletedat（过去分词 + at）
├── 计数：logincount, retrycount（名词 + _count）
└── 状态：orderstatus, paymentstate（实体 + status/state）

CSS类

模式：BEM（块元素--修饰符）或工具类

好：
├── .cardheader--highlighted
├── .navlink--active
├── .forminput--error
└── .btn--primary, .btn--disabled

差：
├── .redButton → 视觉的，不是语义的
├── .leftSidebar → 位置性的，不是语义的
├── .big → 相对于什么？
└── .myComponent → my没有增加任何含义

环境变量

模式：SCREAMINGSNAKECASE，按服务分组

好：
├── DATABASEURL, DATABASEPOOL_SIZE
├── REDISHOST, REDISPORT, REDIS_PASSWORD
├── SMTPHOST, SMTPPORT, SMTPFROMADDRESS
├── APP_SEC