39 lines
2.3 KiB
Markdown
39 lines
2.3 KiB
Markdown
|
# 项目工作指令
|
|||
|
|
|
|||
|
|
本文件作用域覆盖整个仓库。
|
|||
|
|
|
|||
|
|
## 触发规则：对代码进行命名优化
|
|||
|
|
|
|||
|
|
当用户明确提到 `对代码进行命名优化` 时，按以下规则执行，并将其视为本项目内的长期指令。
|
|||
|
|
|
|||
|
|
### 目标
|
|||
|
|
|
|||
|
|
命名优化的核心目标不是“机械改名”，而是**消除糟糕命名对阅读和理解代码造成的阻碍**。凡是命名不合理、语义弱、缩写随意、无法体现业务意图、容易误导读者的地方，都属于优化范围。
|
|||
|
|
|
|||
|
|
### 执行原则
|
|||
|
|
|
|||
|
|
1. 优先提升可读性、可理解性和业务语义表达，不做表面化筛查。
|
|||
|
|
2. 不仅检查方法名，也检查局部变量、参数名、返回值变量名、集合名、布尔变量名、DTO/VO 字段名、查询条件对象名、临时变量名等。
|
|||
|
|
3. 对过度泛化或无业务语义的命名进行替换，例如：
|
|||
|
|
- `wrapper` 这类只有技术含义、没有业务上下文的命名，应改为带业务语义的名称，如 `palletQueryWrapper`。
|
|||
|
|
- `plcs` 这类难以理解、缩写随意且影响阅读的命名，应改为清晰表达含义的名称，如 `palletList`、`matchedPallets` 等。
|
|||
|
|
4. 命名必须结合所在上下文，准确表达“这是什么、装的是什么、为什么存在”，避免仅仅因为类型已知就偷懒使用笼统命名。
|
|||
|
|
5. 若原命名已清晰、稳定且符合上下文，不为了“统一而统一”进行无价值改名。
|
|||
|
|
6. 改名时保持行为不变，并同步更新所有受影响引用，避免产生不一致或语义偏差。
|
|||
|
|
7. 绝对不允许修改业务逻辑, 只允许优化代码命名
|
|||
|
|
8. 一段一段的执行命名优化, 当优化完一段后可以简要总结, 然后自动优化下一段
|
|||
|
|
|
|||
|
|
### 判断标准
|
|||
|
|
|
|||
|
|
若一个命名满足以下任一情况，应优先考虑优化：
|
|||
|
|
|
|||
|
|
- 需要读者额外猜测其含义；
|
|||
|
|
- 只能体现技术实现，不能体现业务语义；
|
|||
|
|
- 使用随意缩写，且不是团队普遍认可的标准术语；
|
|||
|
|
- 无法直接看出集合内元素、布尔值含义或对象用途；
|
|||
|
|
- 在当前方法或业务场景中会明显影响阅读流畅度。
|
|||
|
|
|
|||
|
|
### 输出要求
|
|||
|
|
|
|||
|
|
执行这类任务时，应以“提升阅读体验”为首要标准，必要时可在结果说明中指出关键重命名的理由，但不要做与命名无关的顺手重构。
|