编码规约

系统不是一天崩溃的，代码也不是一天变乱的。

一、编码规约缘起

现代软件是多人协作的产物，协作就是生产力，代码80%的时间是在维护状态的无形协作。

代码规范不一致，代码生产力损耗。

帕金森琐碎定理：大家在无关紧要的事情花了大量时间去讨论，在关键性问题上探讨甚少。

1.1 代码规约存在的意义

1. 减少代码的维护成本
2. 改善可读性
3. 提高团队开发的合作效率
4. 锻炼出更加严谨的思维
5. 身心愉快

1.2 规约发展之路

二、 代码格式与命名风格

刷个酷：简单清爽是一种追求。

2.1 两个要求

1. 命名体现代码元素特征

1. 抽象类命名使用Abstract和Base开头
2. 异常类命名使用Exception结尾
3. 测试类以要测试的类名开始，以Test结尾
4. 类型与中括号紧挨相连来定义数组
5. 枚举带上Enum后缀，枚举成员全大写，单词间用下划线隔开

2. 命名最好望文知意

1. 使用合适的英文
2. 不要使用不规范的缩写
3. 禁止中英合璧

2.2 变量与方法命名风格

2.3 包、抽象类、接口与实现类命名规约

2.4 代码格式设计与规约

三、常量定义设计与规约

3.1 翻车实例

教训总结： 不允许任何魔法值（即未经预先定义的常量）直接出现在代码中。

教训总结：统一常量一定是统一的管理，统一的维护，统一的使用。

3.2 常量规约

1. 五层复用

1. 跨应用共享常量：放在SDK中
2. 应用内共享常量：放置在一方库
3. 子工程内部共享常量： 当前子工程的constant目录下
4. 包内共享常量：当前包下单独的constant目录下
5. 类内共享变量：直接在类内部private static final定义。

2. 命名规范

全部大写，单词间用下划线隔开，力求语义完整清晰，示例：

最大库存数量： MAX_STOCK_COUNT

缓存失效时间： CACHE_EXPIRED_TIME

用户注册错误： USER_REGISTER_ERROR

四、 注释规约

注释的意义：

五、前后端设计与规约

5.1 前后端联合开发的纠结点

1. 接口名称和风格
2. 如果空集合，返回null还是空集合
3. json组装格式
4. 后台异常的失败提示
5. 错误信息与用户提示透出

5.2 前后端交互API七要求

1. 协议：HTTP/WEBSOCKET
2. 域名和端口
3. 路径
4. 请求方法：POST/GET
5. 请求内容：JSON body/ form data
6. 状态码
7. 响应体

5.3 前后端神坑

Java与JS对数字类型变量处理方式不同，如果数字太大或者精度有要求，最好使用String.

1. 精度计算误差

2. 浮点数表达过程解析

单精度如下图，双精度(11位指数，52位有效数字)

1. 规格化 将数字转换成1.xxxxxx * 2n的格式

2. 位数xxxxx转成二进制，存储在有效数字位；n存储在指数位

3. JS坑

JS没有整形，只有Double浮点数。

Java的Long（64位）传递给前端必须转成科学计数法，而Double只有52位有效数字，就会损失进度。

5.4 URL约定

HTTP请求通过URL传递参数时，不能超过2048字节。

六、总结

约定都来自于血泪史，学习规范，防止跳坑。

每一个约定都有背后的原理和经验，思考学习。