经常听到‘编码风格’这个词,那么什么是编码风格呢?接手项目后,读项目中其他人的代码 你就能感觉到不同编码风格。有的人写的代码很乱,可读性很差,方法逻辑处理耦合度很高,缩进不规范。有的人编码风格很好,代码缩进对齐看起来很规范,注释清晰。这就是编码风格的不同。
一个成熟的公司都会有自己具体的编码要求,像大家熟知的《阿里巴巴Java开发手册》等。有些规范不是强制性要求,但是平时编写代码的过程中稍微一注意,代码的可读性就会提高,这样也会显得你很专业。最近正好在修改项目sonar代码扫描出的一些问题,也顺便把自己早期写的一些方法进行了重构,结合自己实际编码经验,把开发过程中可能需要注意的一些编码规范记录下来,方便回顾督促自己养成良好的编码风格。
命名风格
- 类名约定俗成用UpperCamelCase 风格,遵从驼峰形式,特殊专有名词等除外,如:VIP、BO等。
例子: FlightConnectVo / FlightInfoVo / ConverterUtil
- 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格,遵从 驼峰形式。
例子: flightService / flightInfo / signDao FlightInfoVo flightInfo = new FlightInfoVo()
- 常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,名字不要过长。
例子: private static fianl String ERROR_CODE = "0"
- 枚举类名建议带上 Enum 后缀,常量类名建议加上Constants后缀 见名知意。
例子: SigningEnum / SystemContants
编码规范
- 一个java文件代码行数建议限制在1500行内。
- 一个方法逻辑代码行数建议限制在80行内,单行字符数限制不超过 120 个,超出需要换行(IEDA中120个字符处有一条竖着的分界线)。
- 基本数据类型与包装数据类型的使用标准:所有的 POJO 类属性必须使用包装数据类型。 所有的局部变量使用基本数据类型。
- 集合初始化时,指定集合初始值大小。如果暂时无法确定初始值大小,设置为 16,动态扩容。
例子: HashMap<String,Object> tempMap = new HashMap<>(16)
- 在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码,避免使用 单行的形式:if (condition) statements;
- 除常用方法(如 getXxx/isXxx)等外,不要在条件判断中执行其它复杂的语句,将复 杂逻辑判断的结果赋值给一个有意义的布尔变量名,以提高可读性。 (将判断语句抽出来赋值给一个boolean变量)。
- 推荐使用@Slf4j注解来记录日志。
- try-catch 捕获异常 推荐捕获具体的异常如IOException等,Exception,RuntimeException 一般是不被允许的。catch语句中一般不进行逻辑处理,会进行日志记录。
- 重复多次使用的代码考虑抽取出来作为公共方法,多次使用的字符串应当抽出来作为常量。一般情况下魔法值在代码中是不被允许的。
- 字符串的拼加操作,使用StringBuilder。
注释规约
java中有三种注释方式:
①//… 单行注释
②/…/多行注释(注释内容不会写入javadoc生成的文档中)
③/**…/多行注释(注释内容会写入javadoc生成的文档中)
- 类、类属性、类方法的注释必须使用 Javadoc 规范,使用/*内容/格式,不得使用 //xxx 方式。
import java.io.Serializable;
/**
* @ClassName: Student
* @Description: 学生类
* @Author: GaoXiaoQiu
* @Date: 2020-04-03 17:11
* @Version: 1.0
**/
public class Student implements Serializable {
private static final long serialVersionUID = 1999114234471963897L;
/**
* 姓名
*/
private String name;
/**
* 年龄
*/
private Integer age;
}
- 所有的类都必须添加创建者和创建日期
- 方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释 使用/* */注释,注意与代码对齐
- 所有的枚举类型字段必须要有注释,说明每个数据项的用途。
- 代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑 等的修改。并且及时删除无用的注释和代码。
其他相关
- 一个方法的复杂度不应该过高,if else while 等不应过多,一般限制在是十个以内。
- 通常一个方法的 return 限制在三个以内。
- 使用工具类等来简化代码,一些工具类的方法可以减少代码量,提高代码的可读性。
例子: BeanUtils.copyProperties(XXX,XXX); CollectionUtils.isEmpty(list)
- 使用一些java8语法简化代码。
//初始进港段List
List<FlightConnectVo> inFlight = connectFlightVo.getList().stream().filter(
v>inFlag.equals(v.getInOrOut())).collect(Collectors.toList());
- IDEA可以配合一些插件来实时监测代码 如Alibaba Java Coding Guidelines。
SonarQube 简介
SonarQube(sonar)是一个开源平台,用于管理源代码的质量。 SonarQube不只是一个质量数据报告工具,更是代码质量管理平台。 支持java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy 等等二十几种编程语言的代码质量管理与检测。 SonarQube可以从以下七个维度检测代码质量,而作为开发人员至少需要处理前5种代码质量问题。
- 不遵循代码标准
SonarQube可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写。 - 潜在的缺陷
SonarQube可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具检 测出潜在的缺陷。 - 糟糕的复杂度分布
文件、类、方法等,如果复杂度过高将难以改变,这会使得开发人员 难以理解它们, 且如果没有自动化的单元测试,对于程序中的任何组件的改变都将可能导致需要全面的回归测试。 - 重复
显然程序中包含大量复制粘贴的代码是质量低下的,SonarQube可以展示 源码中重复严重的地方。 - 注释不足或者过多
没有注释将使代码可读性变差,特别是当不可避免地出现人员变动时,程序的可读性将大幅下降 而过多的注释又会使得开发人员将精力过多地花费在阅读注释上,亦违背初衷。 - 缺乏单元测试
SonarQube可以很方便地统计并展示单元测试覆盖率。 - 糟糕的设计
通过SonarQube可以找出循环,展示包与包、类与类之间的相互依赖关系,可以检测自定义的架构规则 通过SonarQube可以管理第三方的jar包,可以利用LCOM4检测单个任务规则的应用情况, 检测耦合。
良好的编码风格不是一下就能形成的,只要在日常编码过程中多注意这些规范,习惯成自然,逐渐就会形成自己的编码风格。