（二）改掉这些坏习惯，还怕写不出优雅的代码？

Code Review 是一场苦涩但有意思的修行。

上期分享，通过示例剖析编码中一些经常触犯的性能点，以及编码时常犯的一些小毛病，来告诉新手程序员如何写出健壮的代码。

咱们书接上篇，本次一起来探讨一下，该如何写出优雅的代码？

1. 编码时：少一点不行 

坏习惯一：记录日志时，缺失参数。

反例：

正解：

• 日志打印时，占位符 {} 要严格与参数相对应，如果对应不上，按照截图示意，日志输出则不会打印 queryString 的参数，会直接输出 {}，但是某些版本下会出现空指针异常。
• 说一句废话：图中的 isVarfiy 是什么鬼？莫非是 isVerify，单词好好拼，千万别拼错，不然易被后人拍砖。

坏习惯二：记录日志时，缺失占位符 {}。

反例：

正解：类似的这种问题，多数程序员都犯过。记录日志时占位符少，而参数值多，日志输出时想打印的参数，日志中却没有打印。

如上面截图中代码所示，想输出请求的 queryString，但是由于缺失对应的占位符 {}，则不会打印到日志中。

坏习惯三：使用 switch 时，缺失 default。

正解：

• 采用 switch 时，当所有 case 都不匹配时，会走 default 逻辑。为了程序更完成、更优雅，在一个 switch 块内，都必须包含一个 default 语句并且放在最后，即使它什么代码也没有。
• 说一句废话：截图中的代码格式，尤其是 break 前的分号，你能忍受吗？

坏习惯四：使用 switch 时，缺失 break。

反例：

正解：

• 在一个 switch 块内，每个 case 要么通过 break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；
• 注意 break 是退出 switch 语句块，而 return 是退出方法体。

2. 编码时：多一点不行 

毛病一：看似判 null 很严谨，实则多余。

反例：

正解：这应该是吃过空指针的亏，刚 new 出来的对象，二话不说又判断对象是否为 null，真是多余的判断。

这么写并不能彰显代码很 new B()，反而使代码有失大雅。

毛病二：担心对象使用出现空指针，就疯狂 new。

反例：

正解：创建对象而没有使用，除了白白的浪费内存空间，如果在高并发情况下，效率、内存占用可想而知。

难道上面代码是为了 new B()，百思不得其真解。

毛病三：多分支对应功能却是一模一样。

反例：

正解：

解惑：功能相同的分支进行合并到一起，代码确实能简化不少，优雅不少。

毛病四：闲置不用的对象，到处都是。

反例 1：

反例 2：

正解：闲置不用的对象，到处都是，若留着就是耗内存，而且影响雅观，不用的变量、代码段建议删除。

3.寄语写最后 

常在河边站哪有不湿鞋，金无足赤人无完人，再牛逼的团队，编码都会有出 Bug 的时候。近期微信公众号推出了一个专辑功能，而我迫不及待的想体验。

谁成想，当我点击创建专辑时，输入专辑名称「码农心声」等信息，然后点击保存，却发现列表页面出现了多个「码农心声」，而且赶紧截了个图，不知道是不是个 Bug？ 

But who cares？多出来的直接删除就行啦，又不影响使用。

好了，编码中易犯的那些臭毛病，本次就谈到这里，不知道有多少条是触动了你的心弦，希望有则改之。

一起聊技术、谈业务、喷架构，少走弯路，不踩大坑。会持续输出原创精彩分享，敬请期待！

推荐阅读：

（一）改掉这些坏习惯，还怕写不出健壮的代码？