| name | code_skill |
| description | 编写代码的时候查看这个规范 |
用户编码规范与重构指南
基础交互规则
- 请用中文回答我
- 如果回答的是代码，请给每个关键节点，比较难懂的代码增加中文注释
- 当生成的代码行数超过 20 行时，请考虑聚合代码以及考虑其颗粒度是否适合
代码质量与重构规范
通用编码规范
- 避免不必要的对象复制或克隆
- 避免多层嵌套，提前返回
- 使用适当的并发控制机制
代码坏味道识别与处理
基于Martin Fowler《重构》一书的核心观点，以下是应当注意的代码坏味道及其处理方法：
1. 神秘命名
- 问题：变量、函数、类或模块的名称不能清晰表达其用途和含义
- 处理：重命名为具有描述性的名称，使代码自解释
- 示例：将
fn p()改为fn calculate_price()
2. 重复代码
- 问题：相同或相似的代码出现在多个地方
- 处理：提取为函数、类或模块；应用模板方法模式
- 示例：将重复的验证逻辑提取为共享函数
3. 过长函数
- 问题：函数过长，难以理解和维护
- 处理：提取函数，将大函数分解为多个小函数
- 示例：将200行的处理函数分解为多个职责单一的小函数
4. 过大的类/结构体
- 问题：类或结构体承担了过多责任，字段和方法过多
- 处理：提取类，将相关字段和方法组合成新的类
- 示例：将User类中的地址相关字段提取为Address类
5. 过长参数列表
- 问题：函数参数过多，难以理解和使用
- 处理：引入参数对象，将相关参数组合成对象
- 示例：将
fn create_user(name, email, phone, address, city, country)改为fn create_user(user_info: UserInfo)
6. 发散式变化
- 问题：一个类因为多种原因而被修改
- 处理：按照变化原因拆分类
- 示例：将既处理数据库又处理业务逻辑的类拆分为两个类
7. 霰弹式修改
- 问题：一次修改需要改动多个类
- 处理：将相关功能移到同一个类中
- 示例：将分散在多个类中的订单处理逻辑合并到一个OrderProcessor类
8. 依恋情结
- 问题：一个函数对其他类的兴趣超过自己所在的类
- 处理：移动函数或提取函数
- 示例：将过度使用另一个类数据的方法移动到那个类中
9. 数据泥团
- 问题：相同的数据项总是一起出现
- 处理：提取为对象
- 示例：将经常一起出现的起始日期和结束日期提取为DateRange类
10. 基本类型偏执
- 问题：使用基本类型表示有特定含义的数据
- 处理：使用小对象替代基本类型
- 示例：用PhoneNumber类替代表示电话的字符串
重构过程原则
1. 小步重构
- 每次只做一个小改动，然后测试
- 频繁提交，保持代码随时可工作
2. 测试保障
- 重构前确保有足够的测试覆盖
- 每次修改后运行测试确保行为不变
3. 代码审查
- 重构后进行代码审查，确保质量
- 分享重构经验，提高团队能力
代码可读性优化
1. 命名约定
- 使用有意义的、描述性的名称
- 遵循项目或语言的命名规范
- 避免缩写和单字母变量（除非是约定俗成的，如循环中的i）
2. 代码组织
- 相关代码应该放在一起
- 函数应该只做一件事
- 保持适当的抽象层次
3. 注释与文档
- 注释应该解释为什么，而不是做什么
- 为公共API提供清晰的文档
- 更新注释以反映代码变化
性能相关重构
1. 内存优化
- 避免不必要的对象创建
- 及时释放不再需要的资源
- 注意内存泄漏问题
2. 计算优化
- 避免重复计算
- 使用适当的数据结构和算法
- 延迟计算直到必要时
3. 并行优化
- 识别可并行化的任务
- 避免不必要的同步
- 注意线程安全问题
