12/31Day 孤尽训练营笔记分享

       T31训练营已经进入第12天了，今天讲解的主要内容为编码规约，可能许多小伙伴对于规约都有自己的见解。其实孤尽老师最早版本的《阿里巴巴JAVA开发手册》已经为广大程序员有了一个很好的参考。当然这不是完全要按照规约去做。我们要结合实际开发形成一套在行业内通用的开发形式。

编码规约缘起

     熵增定律： 只要我们没有外力千预代码规范我们的代码总有一天无可救药

  编码规约存在的意义：

     论一个好的编码规约：

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

代码格式与命名风格

  代码风格：简单清爽是一种追求

     命名风格与代码格式一一两个要求

     命名体现代码元素特征

• 抽象类命名使用 Abstract 或 Base 开头
• 异常类命名使用 Exception 结尾
• 测试类命名以它要测试的类名开始，以 Test 结尾。
• 类型与中括号紧挨相连来定义数组。
• 枚举类名带上 Enum 后级，枚举成员名称需要全大写，单词间用下画线隔开。

     命名最好望文知义

• 某些不规范的缩写会导致理解成本增加，比如 condition 缩写成 condi
• 主流的编程语言基本上以英语为基础，此处望文知义的“文” 指的是英文。
• 某业务代码中，曾经出现过 DazePromotion

     包、抽象类、接口与实现类命名规约
        要求：只要按规约设计，就可以做到层次分明，见名知义

  常量定义设计与规约

    不允许任何魔法值（即未经预先定义的常量）直接出现在代码中。
统一常量一定是需要统一的管理，統一的维护，统一的使用

    统一常量一定是需要统一的管理，統一的维护，统一的使用

    【推荐】常量的复用层次有五层;跨应用共享常量、应用内共享常量、子工程内共享常量、
包 内共享常量、类内共享常量。

• 跨应用共享常量：放置在SDK中
• 应用内共享常量：放置在一方库中
• 子工程内部共享常量：即在当前子工程的 constant 目录下
• 包内共享常量：即在当前包下单独的 constant 目录下
• 类内共享常量：直接在类内部 private static final 定义

    常量命名应该全部大写，单词间用下画线隔开，力求语义表达完整清楚，不要嫌名字长，比如：

• 最大库存数量命名：MAX STOCK_ COUNT
• 缓存失效时间命名：CACHE_EXPIRED_TIME
• 用户注册错误：USER_REGISTER_ERROR

注释规约

  注释的误解

• 没啥用，反正不影响编译
• 为了怕老板说我没有注释
• 增加代码行数
• 对简单英文单词的傻瓜式翻译

  注释的作用

• 提高代码可读性
• 使程序条理清晰
• 方便后期代码维护
• 方便程序员间的交流沟通
• 生成帮助文档
• 警示作用防止踩坑

  通俗说法

前后端设计与规约

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

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

    前后端交互的 API，需要明确协议、域名、路径、请求方法、请求内容、状态码、响应体。

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

  为什么要有科学计数法

表示极大数、表示极小数、浮点数的表示范围

• Float：比特数为32，有效数宇为7位（十进制），数值范围为-3.4E+38 和3.4E+38
• Double：比特数为64，有效数宇为16（千进制），数值范围为-1.7E-308和1.7E+308l