naming-buddylisted

# naming-buddy — 命名困难症救星 给一段逻辑/用途描述 + 目标语言,得到 **3-5 个候选名**、推荐理由、以及原名/坏味道诊断。 告别 `data`、`temp`、`flag`、`info`、`manager`——让名字直接说清意图。 ## 何时触发 用户说: - `/naming-buddy` - `帮我起个名字` - `这个变量叫什么好` - `给这个函数命名` - `命名建议` - `这个名字好不好` - `xxx 这个名字有没有问题` - `帮我看看这几个命名` - `类名怎么起`、`文件名叫什么`、`常量名叫什么` ## 工作流 ### 第 1 步:搞清三件事 在给出任何候选名之前,必须先明确: 1. **命名类型**:变量 / 函数 / 类 / 接口 / 文件 / 包 / 常量 / 布尔 / 枚举 / 参数 2. **目标语言**:决定 case 惯例(camelCase / snake_case / PascalCase / kebab-case / UPPER_SNAKE_CASE) 3. **职责描述**:它做什么、存什么、代表什么——这是命名的根本依据 若用户没有提供语言或职责描述,**先追问**,不要凭空猜测。追问示例: - "请问是哪种语言?Go / Python / TypeScript / Java / Swift / Rust / Dart…?" - "能描述一下这个函数/变量的具体职责吗?它做什么事情?" - "它是个布尔值还是函数?读来还是写去?" ### 第 2 步:给 3-5 个候选名 按推荐度从高到低排列,格式: ``` 候选名(按推荐度排): 1. <名字> — <一句中文理由:为什么推荐,有什么优势> 2. <名字> — <一句中文理由> 3. <名字> — <一句中文理由> [4. <名字> — (适用特定场景时)] [5. <名字> — (适用特定场景时)] ``` **给候选名的原则:** - 第 1 名:最符合该语言惯例 + 意图最清晰的 - 第 2-3 名:语义相近但侧重点不同(更简洁 / 更明确 / 更符合项目词汇表) - 第 4-5 名:适用于特定上下文(如有对应配对名、领域术语时) - 每个名字都附一句中文理由,说明**为什么**而不只是"这样更清晰" ### 第 3 步:坏味道诊断 若用户给出了原名,或候选时需要对比,**主动指出**以下坏味道: | 坏味道类型 | 典型例子 | 问题所在 | |-----------|---------|---------| | 过于泛化 | `data`、`info`、`result`、`value`、`item`、`obj` | 什么都能叫这个,看不出业务含义 | | 动作名词太泛 | `manager`、`handler`、`processor`、`util`、`helper`、`service`(滥用) | 掩盖真实职责 | | 临时占位 | `temp`、`tmp`、`foo`、`bar`、`xxx`、`test2` | 临时名字进了正式代码 | | 布尔无前缀 | `verified`、`active`、`loaded` | 不加 is/has/can 容易误用为名词 | | 匈牙利命名 | `strName`、`boolFlag`、`intCount` | 类型信息放名字里,现代 IDE 已无必要 | | 过度缩写 | `usrCntr`、`getMsgCnt`、`calcR