可以按部就班执行的代码规范

1.注意命名

原则:能让别人第一次看到你命名的类名，方法名，常量名就知道你定义的这个类,或者方法，或者常量代表的含义，能选长完整的单词，就别选自己缩短的简称，但是业界固定的简称推荐写简称，命名很容易被很多人忽视比如我，都想快点把逻辑需求写完，一个命名你让我搞十分钟。常常随便命名，以至于很久回头看自己的代码，都想骂自己为啥这样写，这个方法是干啥的。我觉得好的代码命名就是让实习生都能看懂你要在代码中表达的业务逻辑。能看懂你的代码的意思，代码可读性高可减少很多不必要的麻烦，现在你只需要重视命名并在书写代码的时候注意有意识的想好的命名。

2.好的注释

原则：如果不需要写注释，那么最好不写，如果你觉得需要那就写明注释是：

1） 代码是做什么的？

2） 你为啥必须这样写？

3） 你的代码主要逻辑？

注释就是用最短的话表达最核心的思想。

3.好的方法行数

原则：方法或者一段连续的逻辑，别超过一屏的大小，本人用的是mac电脑，idea显示代码区域一般能拉到50几行的样子，如果你需要看日志信息，把idea的日志栏调高些，代码显示区域就不会达到50行，所以最合适的大小个人认为最好不超过50行。那么需求超过50行了咋办？那就需要拆分成小的方法，让方法调方法实现代码行数变短的问题。尤其是写的if和else逻辑 if的大括号一屏幕看不完，当拉下去读到else的时候，if的条件被翻上去了，很容易忘记if的条件是啥，又为啥这样写else的逻辑。这种情况就需要拆分，把if里面的拆到一个方法，else拆到另一个方法。让人一看见这几行代码就知道你写if和else的业务逻辑。

4.if else和if的选用

原则：我有段时间很不愿意写else，能用多个if或者一个if下面直接接业务逻辑实现if和else的逻辑，我都坚决不写else。这个不同人有不同做法按需选择 举例：

public String test(int type) {
      if (type == 1) {
          //代码1逻辑
          return "1";
      } else {
          //代码2逻辑
          return "2";
      }
}

变成：

public String test(int type) {
      if (type == 1) {
          //代码1逻辑
          return "1";
      }
      //代码2逻辑
      return "2";

}

或者

 public String test(int type) {
        if (type == 1) {
            //代码1逻辑
            return "1";
        } else if(type==2) {
            //代码2逻辑
            return "2";
        }else{
            //代码3逻辑
            return "3";
        }

    }

变成：

 public String test(int type) {
        if (type == 1) {
            //代码1逻辑
            return "1";
        }
        if (type == 2) {
            //代码2逻辑
            return "2";
        }
        //代码3逻辑
        return "3";

    }

5.一行代码最合适的长度

原则：如果一行代码要左右拉才能看完，就是太长了，如果两行代码合成一行不用拉也能看完，那就合成一行代码。

6.代码加多余空行

原则：好的做法就是一块业务逻辑完了加一行空行。

7.删除多余的无用引入

原则：不用的import及时删掉。

8.自顶向下编程

原则：就是代码先写整体框架把整体框架写在一起，让人一看就知道你这个方法主要写的业务逻辑，再在这个总的代码里面去调用你写的具体每个业务的实现细节代码。

9.函数参数个数

原则：避免函数参数过多，一般如果超过三个参数，就该考虑是不是封装成实体传输调用。

10.单一原则

原则：如果是两种不同的业务逻辑就不要写在一个方法中，将两种业务拆分，不要写在一个方法里面用业务代码if else去区分调用。这样你以后改其中一个业务逻辑的时候，就会动整个方法会影响另一个业务逻辑，这样就不遵循单一原则。分开两个方法写就不会相互干扰了。

11.写短小简洁的代码

原则：尽量写短小的方法/函数，如果你的代码全是十几行代码的函数组成，恭喜你你已经是大神了。

12.代码层次

原则：if里面再嵌套if这种不能超过三层，到第三层你就要需要合并条件让层次变浅。就像不能用两个for循环一样,我遇见很多情况的双层for循环的需求用HashMap能解决掉。

13.重复代码的封装

原则：一个代码逻辑写了两遍，你就需要封装成一个接口，让多处调用。

14.业务代码下沉

原则：我见过很多代码大家都在控制这一层写，写完就返回给前端，如果下次我遇见个需求和写在控制层的代码相同，但是我后台总不能直接调用控制层吧，那如果你开始写的时候这块代码写成接口形式下沉到service层，那么我想复用直接调用接口就成。就是要面向接口编程。

15.尽量写业界熟悉的判断逻辑

原则：什么意思呢，比如我见过有个需求，是拿一个code去数据库查询，如果数据库查询到就更新，查询不到就需要新增，一般我们判断对象是否为null，但是我遇见的代码是查询出记录数，然后根据记录里面的id是否大于0判断数据库是否存在，大于0那么就是更新逻辑，反之就是数据库不存在，因为一般mysql的id都是从1自增的，他这样判断没有任何问题，但是我当时读这段代码的时候，我看了很久我以为有啥深层次的含义，最后看明白了就是判断新增还是更新。

16.魔法值

原则：这个是最容易出现的，也最容易改的，很多代码里面的判断条件或者case里面全是1，2，3这种魔法值，一旦有新人进来，这种魔法值还没有注释，谁都不知道这一堆阿拉伯数字代表啥意思，让人想死的心都有，这种好的做法是定义枚举，说明1，2，3代表的具体业务逻辑，新人一看就知道这些值是代表啥含义。

17.尽量别自己判断非空

原则：用好@NotNull和@NotEmpty和@NotBlank你能省很多业务代码的判断。

18.养成追求完美代码的习惯

原则：完美的代码根本不存在，你只需要有写成好的代码的觉悟，和下意识的注意代码规范，使整个团队养成统一的代码规范，还有在写完代码测试阶段，也是你重构代码最容易最快最好的时间，那段时间你对业务熟悉，对需求熟悉，对自己写的代码熟悉，按规范重构就很快也不容易出错，时间太久对需求，对代码熟悉程度都下降，能看懂就不错了重构和按规范更无从谈起，所以大佬都不是一开始就写出优雅的代码的，都是一步一步重构出来的。一开始谁都想不出规范的代码，先大体框架和思路没问题，写出整个逻辑再重构。

完