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