日常工作中需要注意的Java编码规范

经常听到‘编码风格’这个词，那么什么是编码风格呢？接手项目后，读项目中其他人的代码 你就能感觉到不同编码风格。有的人写的代码很乱，可读性很差，方法逻辑处理耦合度很高，缩进不规范。有的人编码风格很好，代码缩进对齐看起来很规范，注释清晰。这就是编码风格的不同。

一个成熟的公司都会有自己具体的编码要求，像大家熟知的《阿里巴巴Java开发手册》等。有些规范不是强制性要求，但是平时编写代码的过程中稍微一注意，代码的可读性就会提高，这样也会显得你很专业。最近正好在修改项目sonar代码扫描出的一些问题，也顺便把自己早期写的一些方法进行了重构，结合自己实际编码经验，把开发过程中可能需要注意的一些编码规范记录下来，方便回顾督促自己养成良好的编码风格。

命名风格

1. 类名约定俗成用UpperCamelCase 风格，遵从驼峰形式，特殊专有名词等除外，如：VIP、BO等。
   例子： FlightConnectVo / FlightInfoVo / ConverterUtil
2. 方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，遵从 驼峰形式。
   例子： flightService / flightInfo / signDao FlightInfoVo flightInfo = new FlightInfoVo()
3. 常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，名字不要过长。
   例子： private static fianl String ERROR_CODE = "0"
4. 枚举类名建议带上 Enum 后缀,常量类名建议加上Constants后缀 见名知意。
   例子： SigningEnum / SystemContants

编码规范

1. 一个java文件代码行数建议限制在1500行内。
2. 一个方法逻辑代码行数建议限制在80行内，单行字符数限制不超过 120 个，超出需要换行(IEDA中120个字符处有一条竖着的分界线)。
3. 基本数据类型与包装数据类型的使用标准：所有的 POJO 类属性必须使用包装数据类型。 所有的局部变量使用基本数据类型。
4. 集合初始化时，指定集合初始值大小。如果暂时无法确定初始值大小，设置为 16，动态扩容。
   例子： HashMap<String,Object> tempMap = new HashMap<>(16)
5. 在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免使用 单行的形式：if (condition) statements;
6. 除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复 杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。 （将判断语句抽出来赋值给一个boolean变量）。
7. 推荐使用@Slf4j注解来记录日志。
8. try-catch 捕获异常 推荐捕获具体的异常如IOException等，Exception,RuntimeException 一般是不被允许的。catch语句中一般不进行逻辑处理，会进行日志记录。
9. 重复多次使用的代码考虑抽取出来作为公共方法，多次使用的字符串应当抽出来作为常量。一般情况下魔法值在代码中是不被允许的。
10. 字符串的拼加操作，使用StringBuilder。

注释规约

java中有三种注释方式:
①//… 单行注释
②/…/多行注释（注释内容不会写入javadoc生成的文档中）
③/**…/多行注释（注释内容会写入javadoc生成的文档中）

1. 类、类属性、类方法的注释必须使用 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;
   }
   

2. 所有的类都必须添加创建者和创建日期
3. 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释 使用/* */注释，注意与代码对齐
4. 所有的枚举类型字段必须要有注释，说明每个数据项的用途。
5. 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑 等的修改。并且及时删除无用的注释和代码。

其他相关

1. 一个方法的复杂度不应该过高，if else while 等不应过多，一般限制在是十个以内。
2. 通常一个方法的 return 限制在三个以内。
3. 使用工具类等来简化代码，一些工具类的方法可以减少代码量，提高代码的可读性。
   例子： BeanUtils.copyProperties(XXX,XXX); CollectionUtils.isEmpty(list)
4. 使用一些java8语法简化代码。

 //初始进港段List
 List<FlightConnectVo> inFlight = connectFlightVo.getList().stream().filter(
 		v>inFlag.equals(v.getInOrOut())).collect(Collectors.toList());

5. IDEA可以配合一些插件来实时监测代码 如Alibaba Java Coding Guidelines。

SonarQube 简介

SonarQube(sonar)是一个开源平台，用于管理源代码的质量。 SonarQube不只是一个质量数据报告工具，更是代码质量管理平台。 支持java, C#, C/C++, PL/SQL, Cobol, JavaScrip, Groovy 等等二十几种编程语言的代码质量管理与检测。 SonarQube可以从以下七个维度检测代码质量，而作为开发人员至少需要处理前5种代码质量问题。

1. 不遵循代码标准
   SonarQube可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写。
2. 潜在的缺陷
   SonarQube可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具检 测出潜在的缺陷。
3. 糟糕的复杂度分布
   文件、类、方法等，如果复杂度过高将难以改变，这会使得开发人员 难以理解它们, 且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试。
4. 重复
   显然程序中包含大量复制粘贴的代码是质量低下的，SonarQube可以展示 源码中重复严重的地方。
5. 注释不足或者过多
   没有注释将使代码可读性变差，特别是当不可避免地出现人员变动时，程序的可读性将大幅下降 而过多的注释又会使得开发人员将精力过多地花费在阅读注释上，亦违背初衷。
6. 缺乏单元测试
   SonarQube可以很方便地统计并展示单元测试覆盖率。
7. 糟糕的设计
   通过SonarQube可以找出循环，展示包与包、类与类之间的相互依赖关系，可以检测自定义的架构规则 通过SonarQube可以管理第三方的jar包，可以利用LCOM4检测单个任务规则的应用情况， 检测耦合。

良好的编码风格不是一下就能形成的，只要在日常编码过程中多注意这些规范，习惯成自然，逐渐就会形成自己的编码风格。