对编码进行规约的好处

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

代码格式与命名风格

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

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

2. 命名最好望文知义，不要使用不知意义的缩写及拼音命名变量。

如何定义常量

不允许魔法值及未定义的常量出现在代码中,且常量的定义使用全大写字母表示。

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

注释的作用：

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

前后端设计与规约

1. 后端联合开发的纠结点：

   1. 接口名称和风格
   2. 如果空集合，返回null还是空集合？（规范文档中强制要求返回空集合或空数组）
   3. json组装格式
   4. 后台异常的失败提示
   5. 错误信息与用户提示透出

2. 交互的API,需要明确协议、域名、路径、请求方法、请求内容、状态码、响应体
   说明：
   1） 协议：生产环境必须使用 HTTPS。
   2） 路径：每一个 API 需对应一个路径，表示 API 具体的请求地址：
   a） 代表一种资源，只能为名词，推荐使用复数，不能为动词，请求方法已经表达动作意义。
   b） URL 路径不能使用大写，单词如果需要分隔，统一使用下划线。
   c） 路径禁止携带表示请求内容类型的后缀，比如".json",".xml"，通过 accept 头表达即可。
   3） 请求方法：对具体操作的定义，常见的请求方法如下：
   a） GET：从服务器取出资源。
   b） POST：在服务器新建一个资源。
   c） PUT：在服务器更新资源。
   d） DELETE：从服务器删除资源。
   4） 请求内容：URL 带的参数必须无敏感信息或符合安全要求；body 里带参数时必须设置 Content-Type。
   5） 响应体：响应体 body 可放置多种数据类型，由 Content-Type 头来确定。