1. 编码规约

1.1 编码规约存在的意义

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

1.2 代码风格与命名格式

命名提现代码元素特征

1. 抽象类命名使用Abstract或Base开头
2. 异常类命名使用Exception结尾
3. 测试类命名以它要测试的类名开始，以Test结尾
4. 类型与中括号紧挨相连来定义数组
5. 枚举类名带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开 命名最好望文知义
6. 某些不规范的缩写会导致理解成本增加，比如condititon缩写成condi
7. 主流的编程语言基本上以英文为基础，此处望文知义的文指的是英文
8. 某业务代码中，曾经出现过DaZePromotion

1.3 常量定义设计与规约

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

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

常量命名应该全部大写，单词间用下划线隔开，力求语义表达完整清楚
，不要嫌名字长
1. 最大库存数量命名： MAX_STOCK_COUNT
2. 缓存失效时间命名：CACHE_EXPIRED_TIME
3. 用户注册错误： USER_REGISTER_ERROR

1.4 注释规约

1. 提高代码可读性
2. 使程序条理清晰
3. 方便后期代码维护
4. 方便程序员间得交流沟通
5. 生成帮助文档
6. 警示作用，防止踩坑

2 前后端设计与规约

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

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

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

2.2 浮点数

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

2.3 参数

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

·