Code Review 是一场苦涩但有意思的修行。
书接上篇,本次一起继续探讨一下,该如何写出优雅的代码?
1
编码时:搞的复杂并不好
坏习惯一:多余的 if/else。
类似上面这种写法,if/else 就显得有点高射炮打蚊子,有的同学就会按照下面方式进行简化。
addBool = (i == 0) ? true : false;
这种方式简化当然跑起来没问题,代码确实简化了不少,但是还是略显冗余啊。
正解:
addBool = (i == 0);
坏习惯二:多余的 else。
仅以上图为例,每次看到类似截图中的代码,心里都发毛,完全可以提前 return,进而干掉 else 分支。
心声:
1. 简单就是美,代码写的越少,犯错的几率就越小。
2. 提前终止程序,绝大多数情况下,会节省很多不必要的开销(会减少很多无效的判断,减少无效变量、对象的创建)。
3. 每种编程语言都离不开 if/else 进行条件判断,如果在编码时,存在过多的 if/else 嵌套,代码的可读性就会下降,后期维护难度就会大大提高。
2
编码时:不善于用轮子
毛病一:随处可见的判空逻辑。
反例:
if(merId == null || "".equals(merId)) {
//do something
}
程序为了避免 NPE,很多时候都需要做非空检查,当然上面这种检查方式很有效,只是项目中有太多的属性字段等待去校验,如果到处都是类似的判断,确实有点不太雅观。
很多同学会想着,自己封装 StringUtils 工具类,其实更推荐大家使用三方的轮子。
推荐1:Apache commons-lang 工具包
if(StringUtils.isBlank(merId)) {
//do something
}
推荐2:谷歌的 Guava 工具包
if(Strings.isNullOrEmpty(merId)) {
//do something
}
心声:
1. Apache Commons 下面的工具包,用熟了,确实很香。
2. 谷歌的 Guava 工具包也不错,该类库经过高度的优化,方便我们快速编码,能规避不少编码错误。
毛病二:完成对象间的属性 Copy,编写冗长的代码。
反例:
... ...
batchEntity.setNotifyType(batchEntityOld.getNotifyType());
batchEntity.setUpdatedTime(batchEntityOld.getUpdatedTime());
batchEntity.setBizType(batchEntityOld.getBizType());
batchEntity.setMerchId(batchEntityOld.getMerchId());
... ...
正解:
方式 1:采用 Apache BeanUtils 完成属性赋值。
BeanUtils.copyProperties(batchEntityOld,batchEntity);
方式 2:采用 Spring BeanUtils 完成属性赋值。
BeanUtils.copyProperties(batchEntity,batchEntityOld);
对的,你没看错,方法名称、参数都一样,但是 target、source要注意(稍有不慎,就入坑啊!)
不过,这里更推荐使用 Spring BeanUtils,而且在阿里开发规约中也明确强制使用 Spring BeanUtils 完成属性的 copy。
另外,为什么不建议使用 Apache BeanUtils 呢?看看源码就知道啦。
性能问题,估计跟日志输出、类型判断、用 + 号进行字符串拼接等脱不了关系。
3
寄语写最后
精妙的代码简洁明了,如果将这个代码给其他程序员看,他们会说:“哇,这代码写得真好。”那感觉很像在写一首诗。
我等采石之人当心怀大教堂之愿景——《程序员修炼之道》。
在一个项目的整体结构之内,总有空间展示个性和匠心……百年之后,我们的技艺或许如今日的土建工程师看待中世纪大教堂建造者使用的技法一样陈旧,但是我们的匠心却会得到尊重——匠人精神。
好了,本次就谈到这里,一起聊技术、谈业务、喷架构,少走弯路,不踩大坑。会持续输出原创精彩分享,敬请期待!
推荐阅读:
(一)改掉这些坏习惯,还怕写不出健壮的代码?
(二)改掉这些坏习惯,还怕写不出优雅的代码?
坚持是一种信仰,在看是一种态度!