- Getter 模板修改
开发过程中，经常会遇到空指针异常，尤其是在线上 bug 中，由于未进行 null 判断处理导致的 bug 比例肯定不低。
另外，model 层经常需要根据服务端接口返回的数据结构进行建模，实体类中常见的有 String 类型和 List 类型的字段。而服务端的接口文档里通常都会说明哪些字段不会为空，所以移动端建模后使用相应的实体类数据时，很少或者说会经常性忘记去做 null 判断处理。
正常场景下，也许测不出 null 异常的问题，但如果服务器出了问题，返回了错误的数据，或者在某些特殊的场景下，某些字段的值偏偏就是 null，那么此时如果在使用的地方没有进行 null 判断处理，经常就会有问题出现，如果 app 刚好又有缓存策略，那么可能会导致特别严重的问题。
鉴于此，我是建议，在建模创建实体类时，如果有 String 类型和 List 类型的变量时，这些类型的 getXXX() 方法中直接进行 null 判断处理，确保不会返回 null 值，这样外部使用时就不用再去进行 null 判断处理。如下：
private String mString;
private List<String> mList;
//如果String类型的字段为空，那么返回""，外部在使用getString().equal()等之类方法时如果忘记进行null判断，也不会造成空指针异常
public String getString() {
return mString == null ? "" : mString;
}
//如果List类型字段为空，那么返回空列表。外部在使用getList().get(i)或者getList().size()等时如果忘记进行null判断，也不会造成空指针异常
public List<String> getList() {
if (mList == null) {
return new ArrayList<>();
}
return mList;
}
这样处理的好处是统一在实体类内部进行 null 判断处理，外部使用的地方无需再一个个的去进行 null 判断处理，如果外部使用时忘记进行 null 判断处理，也不会导致空指针异常。
但，如果每次创建完实体类后都靠开发人员的主观意识来为对应的 getXXX() 方法增加相应的 null 判断处理代码，很不靠谱。一切靠主观意识来遵守的规范都不靠谱，总会由于各种原因，如任务赶，太久未接触等等而忘记。
所以，推荐 getXXX() 方法都通过 Android Studio 来自动生成相应代码，那么，就可以通过修改 AS 的 Getter 方法的模板文件，来达到自动生成相应的 null 判断处理代码，以工具代替手工，一提供效率，二强制遵守规范，三解决靠主观意识不靠谱问题。
- 格式化代码自动整理方法位置
当 app 经过越来越多的迭代，增加越来越多的功能时，项目难免会逐渐庞大起来，有些类里的代码会渐渐多了起来。
为了易于阅读，通常对类里的代码会根据各自的职能划分到一个个方法中，尽量遵守方法的单一职责，这样一来，各个方法之间难免会有关联关系，a 方法调用了 b,c 方法，b 方法调用了 d 方法，等等。
这么多的方法，如果不按照一定的规范来整理、摆放的话，当类里的方法越来越多时，这些方法位置杂乱无章的摆放会给 review 人员的阅读，或者过了很长一段时间后本人回来自己阅读时造成一定的障碍。
常见的是规范有一种是按照权限来归纳整理，private 方法集中在一起，public 方法集中在一起。
还有一种规范是按照就近原则摆放，a 方法调用了 b 方法，那么 b 方法位置就尽量靠近 a，我个人倾向于这一种规范，这样在熟悉一个类里的代码时，从上往下慢慢过下来即可，不同跳过来跳过去的。
那么，同样的问题，靠开发人员的主观意识来遵守这种规范是很不靠谱的。写代码过程中，新建了一个方法时，并不会特别特意的去考虑要将它放在哪，基本就是就近放，这样也还好，还算稍微有些关联，有些顺序。
但，如果是在后期新增功能，在旧代码中又去新建方法时，如果对这个类不熟悉，这时候通常都不会去仔细的考虑新写的方法应该要放在哪，要么就是放最后，要么随手就近，久而久之，类里的方法就会越来越杂乱无章。
所以，一切靠主观意识来遵守规范的行为都不靠谱。
鉴于此，推荐打开 Android Studio 自动整理方法位置的功能，借助工具来遵守规范，提高效率的同时也能写出优美的代码。
教程
Getter模板修改教程
- 随便建个类，写几个属性，然后按快捷键 Alt + Insert 或在代码区域 右键 -> Generate -> Getter，然后会有一个弹框：
- 此时先不要点击 OK 键，先点击右上角的 … 的图标，来修改模板文件：
- 此时只有一份 AS 默认的生成 Getter 方法的模板，要对这份模板进行修改，所以接下去可以选择新建一份新的模板文件或者在原文件上修改都可以，比如我新建了一份 NotNull_getter 模板文件：
- 模板文件需要修改的地方就仅仅是在$(name){…} 代码块里的 return 生成规则，原本规则是统一返回字段值本身，根据规范新增两条规则：增加 String 类型和 List 类型的生成规则。以下是修改后的整个模板文件代码，可以拷贝过去直接使用：
#if($field.modifierStatic)
static ##
#end
$field.type ##
#set($name = $StringUtil.capitalizeWithJavaBeanConvention($StringUtil.sanitizeJavaIdentifier($helper.getPropertyName($field, $project))))
#if ($field.boolean && $field.primitive)
#if ($StringUtil.startsWithIgnoreCase($name, 'is'))
#set($name = $StringUtil.decapitalize($name))
#else
is##
#end
#else
get##
#end
${name}() {
#if ($field.string)
return $field.name == null ? "" : $field.name;
#else
#if ($field.list)
if ($field.name == null) {
return new ArrayList<>();
}
return $field.name;
#else
return $field.name;
#end
#end
}
- 建完新模板文件后点击 OK 键，以后通过右键 -> Generate -> Getter 来生成 getXXX() 方法时，注意一下模板文件选择是否正确，一般首次选择后以后都是默认上一次的:
- 效果，getXXX() 方法都是 AS 自动生成，而且根据修改后的模板，也能保证 String 类型和 List 类型都不会返回null值。
