Naming
面向开发者的 Claude Code skills 套件 | A developer-focused Claude Code skills suite
npx -y skills add Lion-1209/Lion-Skills --skill namingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
为代码标识符（变量/函数/类/文件/API/数据库字段）决定名字时。
SKILL.md
4.4 KB, as published. Nobody here has run it
Naming
概述
名字要回答"它是什么/它做什么"，而不是"它在哪/什么类型"。好名字让代码自解释，坏名字逼读者来回跳转确认含义。
何时使用
- 写代码时卡在取某个名字上
- 觉得现有名字不准、误导，想改
- 设计 API/接口，定资源和字段名
- 想统一一个模块的命名风格
不该用：已在用团队既定规范（遵循即可）；纯格式问题（用 linter）。
核心内容
取名前先搞清四件事
套快速规则前先回答这四个问题，否则会在错的对象上取名。前两个是定性（决定名字的形态），后两个是收口（决定用哪个词）：
- 它是对象还是动作？ 数据/状态/实体 → 名词；行为/操作 → 动词。（这是最根本的一刀，定错了后面全错。）
- 一个职责还是两个？ 像"转换 + 校验"这种复合，先问该不该拆成两个名字——能独立复用/测试就拆，再各自取名。别把两件事塞进一个名字（如
parseAndValidateCsv不如parseCsv+validateRecords）。 - 信息够不够？ 用户只甩"flag 叫啥"不给语义时，先反问"它具体表示什么状态"，别凭猜取名。
- 有歧义吗？ 同名异义/异名同义（项目里既有
login又有auth），先定以谁为基准——通常以领域模型/核心资源名为准，全项目统一。
问题 1 的答案同时决定了下面「快速规则」第一条该走名词还是动词那一支。
快速规则
- 函数/方法用动词：
fetchUser、validateEmail - 变量/属性用名词：
user、emailAddress - 布尔用 is/has/can/should：
isLoggedIn、hasPermission - 避免否定：
isEmpty优于isNotEmpty - 避免无意义词：名词
data/info/helper/manager/util，动词process/handle/do——都说不清做啥 - 少缩写：除非领域通用（
id、url、http，以及csv、json、xml这类格式名）；usr、cfg、tmp别用 - 范围越窄越具体：模块内可简短，全局/API 要自解释
- 一致：同一概念全项目用同一个词（别
user/account/member混用）
before / after
| 不好 | 好 | 原因 |
|---|---|---|
processData(d) | parseCsvToRecords(text) | 说清做什么、入参是啥 |
flag | isLoggedIn | 布尔用 is，表意明确 |
userList | users | 复数即集合，去冗余类型后缀 |
strName | name | 去掉匈牙利记法前缀 |
handleStuff() | sendInvoice() | 动词具体，不抽象 |
UserInfoManager | UserProfile | 去掉无意义 Manager |
转换类动词按数据流向选
"把 A 变成 B"这类操作最容易被塞进万能的 process/handle，丢掉数据流向信息。按输入→输出的形态变化选最贴切的动词：
| 动词 | 数据流向 | 例子 |
|---|---|---|
parse | 文本 → 结构化对象 | parseCsv(text) → Record[] |
serialize | 结构 → 文本/字节 | serializeOrder(order) → JSON 字符串 |
convert / transform | 结构 → 结构（同层级换形态） | convertMsToSeconds、transformUserToDto |
format | 结构 → 展示用文本 | formatDate(date) → "2026-06-22" |
map / reduce | 集合 → 集合/标量 | mapToIds(users)、reduceToTotal(items) |
选名时问自己：**读者看到动词，能不能猜出输入和输出分别是什么形态？**猜不出（如 processData）就换。
API 命名
- 资源用复数名词：
/users、/orders - 嵌套表达从属：
/users/{id}/orders/{oid}/items - 代码内字段 case 跟语言：JS camelCase、Python/DB snake_case。但 API 响应字段是跨语言契约——case 由 API 规范定（通常跟主力前端或团队约定），不跟服务端语言（例：后端 Python 用 snake_case，对外 JSON 仍可 camelCase）
- 动作用 HTTP 方法表达，别塞进 URL：
DELETE /users/123而非/users/123/delete
常见错误
| 问题 | 修法 |
|---|---|
缩写成谜（usrCfg） | 写全，除非领域通用缩写 |
| 同概念多名（user/account/member） | 全项目统一一个 |
匈牙利记法（strName、intAge） | 去掉类型前缀 |
| 过度抽象（Manager/Handler/Util） | 用具体名词 |
| 否定布尔（isNotValid） | 改肯定（isValid） |