孤尽班第12天 -- 编码规约

代码中该用Tab还是空格？真的很无聊，没啥可说的。

帕金森琐碎定理：那些个没用的，但每个人都能说上几句的，总是会消耗会议的大部分时间，而真正需要讨论的重要议题却得不到深入的交流。

（小声bb：这个在新来的员工身上体现最明显。新来的员工正在业务熟悉中，所知不多，但又需要表现，给组员和领导留下印象。所以，在会议上，只要遇上他/她熟悉的话题，自然要好好展示一下。如果这个话题切中正题，这位新员工拔得一筹，即便没切中正题，至少也刷了波存在感，让人觉得他/她还是很有激情的。）

但是，从大局来看，需要讨论的问题总是得不到充分的交流，而时间却在一分一秒地流逝。

编码规约存在的意义：

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

代码格式与命名风格

两个要求

命名体现代码元素特征

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

命名最好“望文生义”

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

常量定义与设计规约

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

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

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

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

（小声bb：我平时的做法是对于那些在全局代码中只会出现一次的string值就不用常量定义了，但只要会被用到两次以上的，都会用创建一个常量来表示这个string值）

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

最大库存数量命名：MAX_STOCK_COUNT

缓存失效时间命名：CACHE_EXPIRED_TIME

用户注册错误：USER_REGISTER_ERROR

注释规约

注释作用：

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

时间紧张，无法出高质量的代码？

应该在下面这些方面提高自己的能力

沟通效率，协作效率，打字速度，环境调试，代码意识，架构意识，代码注释

前后端设计与规约 

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

1. 接口名称和风格

2. 如果空集合，返回null还是空集合

3. json组装格式

4. 后台异常的失败提示

5. 错误信息与用户提示透出

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

把errorMesage和抛给用户的提示信息映射起来，不应该把错误信息直接抛给用户。

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