前言：最近项目组内部在做CodeReview，将我们在日常工作中编写的代码进行一个评审，发现潜在问题，然后收集、整理、讨论、形成规范，指导后续软件开发，提升软件质量。以下是个人的一期总结，后续将不定期陆续更新完善此规范。
1.命名、注释和提示：
（1）.命名方法时，首字母不能为大写，哪怕是单词的缩写也不能为大写。如HgSetToHgInfo,必须改成hgSetToHgInfo。
（2）.命名要规范，易理解，与方法执行的目的或作用保持一致。例如，获取数据列表，命名应为getHolidayGuardsByWatchId，而不是getWatchIdHolidayGuards。
（3）.关于注释，可利用方法和变量的命名来理解业务逻辑，或者用注释来说明方法的用途和注意要点，两者酌情而定。
（4）.定义了未使用的对象或变量，编译器会提示此多余代码，在AndroidStudio编译器中，代码提示中有黄色提示的，即多余的变量，一定要进行处理。
2.网络请求：
（1）.网络请求,不能直接return掉，return掉之后，请求会一直在哪儿，没有返回，调用者无法做相应处理。
（2）.在网络请求之前，不需要返回数据，listener可为空。
3.Log日志：
（1）.在调试程序时，统一使用LogUtil，便于发布版本时控制Log的开关，可针对个人需要在特定模块Log中增加Tag。
（2）.Log Level需要根据实际情况和规范来写，不能到处写error级别的Log。
4.判断方法：
（1）.判断变量x是否为null时，统一为 x == null，不能写成null == x;
（2）.方法体内，有过长的判断时，尽可能抽调出来，新建临时变量来判断，使代码结构清晰，便于阅读。
（3）.网络请求返回object时，有些地方有判断是否为空，有些地方未判断是否为空，前后不一，需保持一致。
5.数据处理：
（1）.方法命名了getData，但是在内部又进行了本地缓存数据的删除等操作，需要考虑重命名，减少歧义，或是将本地数据删除操作等封装出来。
（2）.执行数据库删除操作时未对成功或失败的情况做处理，当因为不可知因素删除失败时，需要对失败情况进行处理，如重执行，输出日志等。
（3）.List返回值时，面对返回null和返回空集合的选择，对于集合和数组作为返回值，使用长度为零的数组或者集合，而不是null，好处是可简化代码，增强程序健壮性，缺陷是会增加微不足道的系统开销。
可简单的概括为：任何在逻辑上表示查找(search或者get)的意思时，应该返回null；当空对象与其他返回对象有一样的行为和意义时，使用空对象。
6.其他：
（1）.Dao在构造函数初始化中new比较好，避免在每个方法体中使用时new临时对象，增加代码行数。但临时对象在使用后可以被及时回收，两种方案需针对具体情况处理。
（2）.单例模式在多个线程密集调用getInstance时，存在创建多个实例的可能。可使用synchronized修饰getInstance方法，但使用此方法后必然会导致性能下降，可使用双重检查加锁，首先进入
该方法时进行null == sInstance检查，如果第一次检查通过，即没有实例创建，则进入synchronized控制的同步块,并再次检查实例是否创建，如果仍未创建，则创建该实例。
