在编程这一行干活，免不了被糟糕的代码绊倒。因为糟糕的代码，导致项目延期和进度缓慢。 架构和设计模式等致力于从“战略”的角度减少糟糕代码，代码规范则侧重于从“战术”的角度减少坏代码

前言

糟糕的代码随着时间的推移对成产力的影响：

之前有写过Android 项目规范，这次主要写一下编码的规范。以下内容从编码的角度列举了一些注意点。

有意义的命名

1. 名副其实
2. 避免误导
3. 做有意义的区分
4. 使用读的出来的名称
5. 避免使用编码
6. 避免思维映射
7. 每个概念对应一词
8. 别用双关
9. 使用可搜索的名称
10. 类名应用名词
11. 方法名应为动词或动词短语
12. 别扮可爱
13. 使用解决方案领域名称
14. 使用源自所涉问题领域的名称
15. 添加有意义的语境
16. 不要添加没用的语境

函数

1. 短小
2. 只做一件事
3. switch 语句
4. 使用描述性的名称
5. 函数参数
6. 无副作用
7. 分隔指令与询问
8. 使用异常替代返回错误
9. 别重复自己
10. 结构化编程
11. 重构函数

格式

1. 横向格式
2. 像报纸学习
3. 概念间垂直方向上的区隔
4. 垂直方向上的靠近
5. 垂直距离
6. 垂直顺序
7. 水平对齐
8. 水平方向上的区隔与靠近
9. 水平对齐
10. 缩进
11. 空范围
12. 团队规则
13. Bob 大叔的格式规则

对象和数据结构

1. 数据、对象的反对对称性
2. 数据传送对象
3. 数据抽象
4. 迪米特法则
   1. 火车失事
   2. 混杂
   3. 隐藏结构

错误处理

1. 使用异常而非返回码
2. 先写 try-catch-finally 语句
3. 使用不可控异常
4. 给出异常发生的环境说明
5. 依调用者需要定义异常类
6. 定义常规流程
7. 别返回 null 值
8. 别传递 null 值

注释

1. 注释不能美化糟糕的代码
2. 用代码来阐述
3. 好注释
   1. 法律信息
   2. 提供信息的注释
   3. 对意图的解释
   4. 阐释
   5. 警示
   6. TODO 注释
   7. 放大
   8. 公共 API 中的 Javadoc
4. 坏注释
   1. 喃喃自语
   2. 多余的注释
   3. 误导性的注释
   4. 循规式注释
   5. 日志式注释
   6. 废话注释
   7. 可怕的废话
   8. 能用函数或变量时就别用注释
   9. 位置标记
   10. 括号后面的注释
   11. 归属与署名
   12. 注释掉的代码
   13. HTML 注释
   14. 非本地信息
   15. 信息过多
   16. 不明显的联系
   17. 函数头注释
   18. 非公共代码中的 Javadoc
   19. 范例

思维导图

本文地址 http://94275.cn/2016/09/14/Code-Spec/ 作者为 Zhenguo