T31Day12编码规约

一、为什么要有编码规约？

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

熵增定理：任何系统在没有外力有序干预下，一定会往混乱无序的方向发展。

代码规范不一致带来的最直接的后果就是代码的生产力损耗。

1.好的代码规约带来的效益：

        减少代码维护成本。

        改善可读性

        提高团队开发的合作效率

        锻炼出更加严谨的思维

        身心愉快

二、代码格式与命名风格

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

        抽象类命名使用Abstract或Base开头：例：AbstractAnimal

        异常类命名使用Exception结尾；例：ProductException

        测试类名以他要测试的类名开始，以Test结束；例：ProductServiceTest

        类型与中括号紧挨相连来定义输入；例：OrderBO[] orderArray；

        枚举类名带上Enum后缀，枚举成员名称要全大写，单词用下划线隔开。

2.命名最好望文知意

        某些不规范的缩写会导致理解成本增加；例：subName

        不要使用拼音和英文混搭命名；例：chanPinName。

        当前主流命名以英文为主，根据各家公司规定不同使用不同的规范，重要的一点是统一~！

3.包名

        包名全小写层级明确，

        Service包下分impl包和Servcie接口

三、常量定义设计与规约

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

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

1.常量定义设计及规约

        注：常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。

        跨应用共享常量：放置在SDK中

        应用内共享常量：放置在一方库中

        子工程内共享常量：即在当前子工程的constant目录下

        包内共享常量：即在当前包下单独的constant目录下

        类内共享常量：直接在类内部 private static final 定义

2.常量定义设计与规约

        注：常量名应该全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字太长；例：

        最大库存数量命名：MAX_STOCK_COUNT

        缓村失效实践命名：CACHE_EXPIRED_TIME

        ps:因为ide自带代码补全，所以不用在一命名长度。

四、注释规约

1.注释的作用：

        提高代码可读性；

        使程序条理清晰；

        方便后期代码维护；

        方便程序员间的交流沟通；

        生成帮助文档；

        警示作用，防止踩坑；

2.注释规约：

        类变量、常量使用文档注释说明表示的意义；

//示例TODO

        类名上使用文档注释标注这个类是干什么用的，作者是谁，什么时候开发的；

//示例TODO

        方法上使用文档注释说明方法执行的功能，参数意义，返回值意义；

//示例TODO

        在实现类中对难以理解的代码使用块注释或单行注释标明下列代码执行的逻辑； 

五、前后端设计规约

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

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