项目开发中代码风格以及规范总结（持续更新...）

前言

相信许多人都将技术学习放在第一位，疯狂的学习框架、技术、原理，但是不要忘了代码coding，工程能力也要跟上，本文将总结工作中的“代码异味”，时刻提醒自己规范代码风格，本文将持续更新，希望有同感的小伙伴留言共同讨论，共同进步。

1. 长函数

在实际工作中，对于代码的业务开发有点“平铺直叙”的感觉，即1. a做了什么，2. b做了什么，3. c做了什么，balabala，结果代码写完一看一两百行，对于这列冗长的函数就属于“代码异味”。首先，代码过长不方便阅读，后期维护困难，其次也不方便对代码进行细致的Review，不利于发现代码潜在问题。所以对于长函数的拆解方式就是，将每一个功能模块单独划分成一个函数，如果步骤多且有关系依赖性，则将其封装在一个大的函数中，将每个小的函数聚合在一块即可，这样代码调用关系清晰，易于维护。

2. 重复代码

TODO

3. 工具类使用

3.1 ObjectUtil.checkNotNull的使用

对于checkNotNull的使用，

String nickName = getNickNameFromDB();
ObjectUtil.checkNotNull(nickName, "nickName");

目的是为了清晰的表达程序意图，并且精确控制出错的位置。

1. 尽早抛出异常
   在方法的入口，或运算开始前，检查数据，而不是等到数据被传递到更深层的方法时被动的触发异常，有助于更精确的确定异常产生的原因。

2. 断言该变量非空
   也就提醒了调用者，如果传入null肯定是错误的，直接去找为什么会是null的原因即可，不用再分析这里到底是要允许null，还是不允许null。

3. 更精确的知道哪个变量是null
   被动抛出的NullPointerException只能定位到行，如果是类似于这种代码
   xxxx.get(0).getAddress().equals(yyyy.getAddress())，你不容易看出到底是哪个变量或中间结果是null的，需要调试或输出一下数据才能确定。

在Java中任由代码对空变量进行操作而导致空指针异常是一种低级错误。

往往很多时候同一段代码不是一个人维护的 或者你需要在时隔很久后去维护它 这个时候谁也不知道改动这些代码会带来哪些隐形bug 对于空指针的检查可以让你在开发过程中提前避免很多因为改动代码带来的以外因素 让问题尽量在开发时暴露而不是上线后暴露，因此要善于使用checkNotNull。