JAVA代码规范

346 阅读5分钟

代码规范

1. 什么才算规范?

在编译器中,不遵守规则编写就会报错,这叫违反规则。

那么规范呢,即是人为约定俗成的行业规范。即使我们不按规范编写,代码依然能够跑通。但是没有规范的代码编写习惯: 一则不利于后期代码维护形成屎山。二则有可能因此受到同事轻视更甚错失晋升机会。

那么如何书写才算规范呢? 新人对于代码规范主要是按部就班的根据约定的规范条例进行严格遵守,并将之转化为自我肌肉记忆。这是一个长期的习惯养成,切不可急于求成。

2. 规范书写的好处

规范的代码首要的好处就是整洁、舒适,一目十行。假如你现在回顾几个月前写的代码很吃力,那么说明你的规范不达标,连作者都无法快速阅读,更别提给同事维护阅读了,只会得到后人的骂声一片。

  • 有助于促进团队协作 多数项目都是团队开发的,如果没有规范的标准,每一个人都各具特色,那么相互之间的代码阅读必将成为留存多年的噩梦回忆。
  • 有效降低BUG出现 代码堆砌中,如果没有按照规范进行,格式错乱,出现BUG时排查困难。规范的代码堆砌、规范的出入参、规范的异常处理、规范的日志输出,说实话是确确实实有助于提高开发效率,降低BUG出现的。
  • 降低维护成本 项目开发到上线只是初始阶段,真正伴随程序猿的应该是运维阶段。运维过程中毫无意外的会出现业务迭代,很多情况都是在原有功能上进行深化需求。这时回顾屎山代码并赋能新迭代,将成为一段不可言说的经历。如同第一点所说的,规范的代码,将拥有较高可读性与推展空间,无疑规范代码是为未来留有可期。
  • 高效Code Review 代码审查我认为是非常有必要的,即时纠正错误,对代码规范与错误代码进行监督排错。团队的代码审查也是学习提升的机会,阅读同事的代码,对新人的成长也是非常有益。但是不规范的代码进行审查的工作量与难度都是不言而喻的,浪费大量时间却收益甚微。
  • 自我提升 以上4点都是基于团队而言。对于个人,优秀规范编写的代码,让人阅读愉悦的同时也能让阅读者对编写者的专业性得到认可。代码规范的码农不一定是大拿,但代码编写都不规范的码农一定不是。

3. 代码规范的方案

1. 命名方式

  • 命名语义化,能够达到顾名思义
  • 使用完整单词,切忌自行缩简单词。
  • 切忌使用a、b、c、d此类神秘编号

一些常见的命名规范:

包的命名 (全部小写,由域名定义) 例如:com.cococo.mall

类的命名 (单词首字母大写)   例如: User

方法的命名 (首字母小写,字母开头大写) 例如:getUserInfo

常量的命名 (全部大写 ,常加下划线) 例如:MAX_VALUE

2.简洁注释

  • 要求:清晰易懂、简洁明了
  • 内容:做什么、为什么

3.方法行数

一个方法内容尽量不超过一屏。如果逻辑过于复杂,就要拆分业务逻辑到为方法。

4.if else 和 if 的选用

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";
}

5.一行代码长度

一屏内看完,一屏装不下就转多行。

6.空行分割

方法之间用空行分割,让各模块清晰可见

7.删除多余代码

如无用的 import 内容应及时删除

8.方法入参数量

如果一个方法的入参大于3个,就应该考虑封装成实体进行传输

9.单一原则

如果两个不同的业务写在一个方法中,用 if else 去区分调用,后期想要调整的时候就有可能相互干扰。 应该要遵循单一原则,一个方法内尽可能写独立的功能。

10.代码层次

  • if的嵌套不超过3层
  • for循环嵌套不超过2层

11.代码封装

如果一段代码出现过2次及以上。就必须封装成为接口,由多处调用。

12.业务代码下沉

很多新人编写代码都喜欢直接在controller里编写。这样的写法导致代码无法复用,应下沉到service层再由controller直接调用。

13.魔法值

这个是最容易出现,也最容易修改的。很多时候我们会为了减轻工作量,用1、2、3、4这种魔法值来定义对应的类型。导致同事读取代码时无法第一时间判定1、2、3、4所代表的含义。建议做成枚举或常量去定义1、2、3、4所代表的具体业务逻辑。

14.非空判断

非空判断不要自己写!

  • @NotNull://CharSequence, Collection, Map 和 Array 对象不能是 null, 但可以是空集(size = 0)。
  • @NotEmpty://CharSequence, Collection, Map 和 Array 对象不能是 null 并且相关对象的 size 大于 0。
  • @NotBlank://String 不是 null 且去除两端空白字符后的长度(trimmed length)大于 0

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

参考

极客时间专栏,《软件设计之美》,郑晔 雷小鸿