1.引子
每个公司，每个团队都应该有一套编码规范，或正式或非正式。比如变量该如何命名，比如注释该如何写？
那么我们说编码规范它是团队开发习惯的约定，重点不在于某一条细节规定，而是要保持团队成员之间风格的统一，风格统一才是重点。从团队协作的角度来说，通过风格统一，编写出来的项目代码在整个团队成员之间，可读性更好，更容易维护理解；从个人角度来说，有意识的遵守编码规范，更容易写出高质量的代码，更容易提升我们个人的编码能力。
今天让我们一起来聊一聊编码规范，及具体的一些参考约定。
2.编码规范
2.1.命名
命名是编码规范当中，比较重要的一条。大到项目、模块、包的命名；小到类、函数、成员变量的命名。命名一个大的原则是直观达意，看到名字就知道要表达的含义，不需要猜。命名具体的参考规范有
【1】代码中的命名，不要以：下划线或者美元符号开头；不要以：下划线或者美元符号结尾
解释：
1.不是语法约束
2.java中的命名规范：使用字母、数字、下划线、美元符号组成
3.不能以数字开头。其他都可以
4.既然如此，那么本约束可以参考C++，主要是为了防止与标准库中的名称冲突
【2】所有编程相关的命名，严禁使用拼音与英文的混合方式，更不允许使用中文的方式
解释：
1.编程常识，不需要解释
2.目的是避免歧义，让代码更易于阅读、易于理解
【3】类名使用大驼峰命名规范：UpperCamelCase，例外情况：BO/DTO/VO/PO/UID除外
解释：
1.编程常识，不需要解释
【4】方法名、成员变量名、参数名、局部变量名使用小驼峰命名规范：LowerCamelCase
解释：
1.编程常识，不需要解释
【5】常量命名全部大写，中间使用下划线分隔
解释：
1.编程常识，不需要解释
【6】抽象类命名使用Abstract开头、异常类命名使用Exception结尾、测试类命名使用目标测试类开头，以Test结尾、枚举类命名使用Enum结尾，接口名以I开头，接口实现类一Impl结尾
解释：
1.编程常识，不需要解释
【7】数组命名将类型与中括号紧挨相连
解释：
1.把中括号，看成类型的一部分
【8】POJO类中成员变量，禁止以is作为前缀
解释：
1.会引起框架解析序列化错误
2.易采坑（年前项目上线，有小伙伴就在这上面采坑了）
【9】包名称统一使用小写，单数形式，点分隔符之间有且仅有一个自然语义的英文单词
解释：
1.编程常识，不需要解释
【10】禁止不规范的缩写。常用词可以适当缩写，比如String-->str，Document-->doc，Number-->num
解释：
1.望文不知义
【11】模块、接口、类、方法如果使用了设计模式，在命名中包含设计模式标识
解释：
1.编程常识，不需要解释
【12】各层命名规约
Service/Dao层方法命名：
获取单个对象：get作为前缀
获取多个对象：list作为前缀
获取统计值：count作为前缀
只允许新增：insert作为前缀
只运行更新：update作为前缀
允许新增与更新：save作为前缀
删除对象：delete作为前缀
领域模型命名：
数据对象：xxDO
数据传输对象：xxDTO
展示对象：xxVO
POJO：DO/DTO/BO/VO统称
2.2.注释
给代码编写适当的注释，有助于增强代码实现逻辑的理解，增强可读性，不需要猜。这里我们说是适当，适当的意思即是说注释不是越多越好，注释是有维护成本的。比如说一个方法，在后期因需求变化实现逻辑发生了变化，那么方法上的注释需要同步维护。
关于注释，我们需要怎么写呢？我总结了一下，一个好的注释可能包含这么些内容：
- 做什么，直观描述类，函数提供了什么能力
- 为什么，直观描述为什么需要该类，该函数。比如说将旧的接口能力，升级为新接口，写上为什么就很有必要
- 怎么做，将主体实现逻辑，分1，2，3的形式描述出来
2.3.空行
在类中，不同的代码块进行隔离，有助于代码的可读性。比如成员变量，与方法之间；比如方法内不同的实现逻辑块之间。
用好空行，举手之劳，却带来满满的收益
2.4.缩进
良好的代码缩进，是增强代码可读性的保障。根据团队习惯，我们可以选择4个空格，或者2个空格缩进方式。但是需要注意，禁止使用tab缩进
2.5.括号
括号是我们组织代码块的标识，应该遵循统一的约定
【1】如果大括号内为空，简洁的写成{}即可，大括号中间不需要换行和空格；如果是非空代码块：
1.左大括号前不换行
2.左大括号后换行
3.右大括号前换行
4.右大括号后还有else等代码则不换行
【2】左小括号和右边相邻字符之间不出现空格；右小括号和左边相邻字符之间不出现空格
2.6.类、方法、代码行
类、方法、代码行，从不同的角度来看如何组织代码。
- 类，避免出现超大类，比如一个类有上万行代码，那么需要考虑该类是否违背了单一职责原则，需要考虑拆分了
- 方法，一个方法原则上代码行不要过多，推荐在80-100行之间，方便一屏能够完整展示
- 代码行，原则上长度控制在120个字符左右，方便IDE工具能够一行展示，避免过多的换行
2.7.类成员顺序
类的成员主要包含成员变量、方法。其中又分为静态成员，与普通成员；从作用域的角度又分为公有的public，保护的protected，私有的private。我们可以参考如下组织成员之间的顺序
- 先成员变量，后方法
- 先静态，后普通
- 先作用域大的，后作用域小的
2.8.嵌套
嵌套不宜过深，年前在一个遗留系统重构项目中，碰到了近20层的if...else，当时硬是差点没缓过来，非常难受！
因此一定要移除过深的嵌套层次，方法包括
- 去掉多余的 if 或 else 语句
- 使用 continue、break、return 关键字提前退出嵌套
- 调整执行顺序来减少嵌套，将部分嵌套逻辑抽象成函数
2.9.魔法数
禁止在代码中，硬编码出现任何魔法数。编程常识，不需要解释对吧
2.10.参数封装
避免方法中参数过多，尤其是给外部提供接口能力的方法，像这样：method(param1,param2,param3,param4,param5,param6......)，参数过多带来的后果是
- 可读性、易用性不友好，调一个方法，传n多参数，代码还要换行
- 扩展性不好，需求变了，需要增加新的参数怎么办？修改接口声明吗？调用方客户端是不是需要跟着变？
因此最佳实践，通过POJO对象将参数封装起来，一了百了。
最后，以上就是我今天想要分享给你的一些编码规范的参考，期望给你及你们的团队带来一些帮助。你需要注意，我们还是那句话：规范无定式，整个团队统一风格才是重点。
