刚开始实现时,可以不那么严格,写完之后再慢慢优化

命名

1. 见名知义
2. 避免魔鬼数字
3. 类名应该是名词
4. 方法名应该是动词
5. 一词一义,避免一语双关
6. 多个变量整合成一个变量(如分页),或给每个变量添加前缀

函数

1. 尽量短小
2. 单一事件原则
3. 函数参数不为boolean值(boolean参数表示该函数不止做一件事)
4. 开放/封闭原则(增加需求时,扩展新代码,而非修改已有代码)
5. 函数参数越少越好,尽量不要超过3个
6. 多参数书写顺序尽量合理
7. 函数参数过多,可以考虑封装为类
8. 尽量避免输出参数,可以更改类属性来替代
9. 避免重复代码

注释

1. 写好代码,尽量减少注释
2. 注释要随着代码的变动而变动
3. 别注释不用的代码
4. 需要注释的场景
   • 晦涩难懂的参数或返回值
   • 警告
   • 公共API
   • TODO

格式

1. 单个文件的代码行数尽量不超过200行,最多不超过500行最佳
2. 概念相关的代码应该放到一起
3. 被调用的函数,应该放在执行调用函数的下面
4. 变量定义应该放到类或函数的开头

对象和数据结构

1. 化具象(曝露数据,没有提供有意义的函数)为抽象(曝露操作数据的函数,隐藏数据)
2. 面向对象和面向过程: 各有好处,灵活选择
   • 面向过程:
     • 优点: 便于添加新函数
     • 缺点: 添加新类需要更改所有函数
   • 面向对象:
     • 优点: 便于添加新类
     • 缺点: 添加新函数需要每个类都添加
3. 得墨忒耳定律(也叫最少知识原则): 模块不应该了解它所操作对象的内部情形

   // getOptions 函数返回值又调用了 getScratchDir,违反了该定律
   const outputDir = xtxt.getOptions().getScratchDir();
   

单元测试

应遵循以下规则

1. 运行速度快
2. 每个测试点相互独立
3. 可在任何环境中运行
4. 要在开发代码之前写好

参考书籍

• 代码整洁之道(Clean Code)