1.为什么要进行编码规约？
- 熵增定律：当我们没有外力干预代码规范的时候，我们的代码总有一天会无可救药。充斥着毫无混乱的判断，毫无逻辑性的功能。
- 代码不规范，也会导致代码的生产立损耗
- 孤尽老师在这里讲了一个帕金森琐碎定律：当一场讨论的时候，大家会对很琐碎的事情进行各种讨论，但是对核心的问题其实并没有进行很多的讨论。
2. 一个好编码存在的意义
- 减少代码的维护成本
- 改善可读性
- 提高团队开发的合作效率
- 锻炼出更加严谨的思维
- 身心愉悦
3. 代码格式个命名风格
代码要尽量保持简单清爽，能让人第一眼就能看明白意思
- 命名要体现代码元素的特征
- 抽线类命名使用
Abstract或Base开头 - 异常类名使用
Exception结尾 - 测试类名以它要测试的类的类名开头，以
Test结尾 - 类型和中括号紧挨相连来定位数组
- 枚举类名带上
Enum后缀，枚举成员名称需要全大写，单词间要用下划线隔开
- 抽线类命名使用
- 命名最好望文知意
- 某些不规范的缩写会导致沟通成本的增加，比如一个单词就缩写成了前面几个字母
- 主流的编程语言基本上以英文为基础，此处望文知意指的就是英文
- 尽量减少拼音
4. 常量定义设计于规约
- 不允许任务魔法值直接出现在代码中。
- 统一常量一定需要统一的处理，统一的维护，统一的使用。
- 常量的复用层次有下列几层。
- 跨应用共享常量：放置在SDK中
- 应用内共享常量：放置在一方库中
- 子工程内部共享常量：即在当前子工程的 constant 目录下
- 包内共享常量：即在当前包下单独的 constant 目录下
- 类内共享常量：直接在类内部 private static final 定义
- 常量命名应该要全部大写，单词用下划线分隔开，语义要表达完整，不要嫌弃名字太长。
- 可以参考JAVA源码中的注释信息进行编写，他们写的很规范。
5. 注释规约
- 作用
- 提高代码的可读性
- 使程序条理清晰
- 方便后期代码的维护
- 方便程序员之间的交流沟通
- 生成帮助文档
- 警示作用，防止踩坑
- 详细描述
- 是一个附加说明。详细规则和为为什么我要这么设计
- 是一个整体和部分的关系。告诉这段代码为什么要这么设计
- 风险提示。告诉这么设计的不合理，会有什么风险存在
6. 前后段设计于规约
现在基本上所有的公司都是前后端分离的开发项目，此时有一个好的规约就显得尤为重要，可以有效的减少沟通成本，提高开发效率。
- 前后端交互的API，需要明确协议，域名，路径，请求方法，请求内容，状态码，响应体等信息。
- JAVA和JS对数字类型变量的处理方式不同，如果数字太多或者精度有要求的，最好都使用
String类型 - 详细示例，看下面两种情况的输出对比：
为什么上面两种执行的结果不一样呢？明明是相同的算法。这里就涉及到精度的问题了，以及科学计数法的问题了。
Float：⽐特数为32，有效数字为7位（⼗进制），数值范围为 -3.4E+38 和 3.4E+38
Double：⽐特数为64，有效数字为16（⼗进制），数值范围为-1.7E-308和1.7E+30
下面是浮点数的格式：
现在我们有一个0.9的数字，我们把他转为科学计数法就是1.8乘以2的负一次方，1.8转为二进制就是
1.1100110011001100110011001100.... 我们把前面红色的有效数字转为十进制数就是1.799999952316
然后这样可以算出0.9=0.8999999976158，那这样1f-0.9f=0.1000000024，这样就出现了精度计算问题。
还有一个问题就是JS里面没有整形，只有Double浮点数。而Long类型有64位，传给前端必须转为科学计数法，而Double只有16位有效数字，这样就会被截断，最大能够显示的精度就只有2的53次方了。
所以对于前后端的数字太多的规约，最好都使用String进行传值。
4. 对于Http请求通过URL传递参数时，不能超过2048个字节
