前几天线上出现一个bug，一个简单业务逻辑错误的bug，代码如下图1（项目组内一个同事写的代码）：
图1d
bug的原因很简单，只是时间段判断错误，没有什么值得追究的，写这段代码的同事把判断条件改一改也就把bug修复了，但是我实在看不下去了，于是动手帮他把代码重构，如下图2：
图2
图2代码逻辑与图1代码逻辑一致，但是代码的结构却相差甚远，一个看了让人感觉异常复杂，一个看了赏心悦目，通俗易懂。（图2的代码最后一个else可以去掉， return false直接放外面就好了，其中的异常处理也让他改了）
这一段非常简单的业务逻辑代码，恰恰能体现一个程序员的编程功底及对代码的领悟能力和写代码时的态度，再次印证一个简单哲学：把复杂的事情做简单是相当不容易，把简单的事情搞复杂，那是相当容易。
这段代码也体现出if else return的应用恰当，能让代码结构看上去简洁美观，逻辑清晰。
这里说说我对if else的使用心得：
通常情况下，如果能不写else，我是坚决不写else，能用return提前结束代码的执行，就马上用。
当然会存在一些逻辑让你使用else比不使用else更好，但这种场景也是相当的少，在写这篇文章的时候，我去github上Linus的主页翻看linux内核源码，统计了net目录下4个代码文件（每个文件超过一千行代码），发现每个代码文件中else保持在10个左右。使用else代码的共性是它们是互斥的，且程序还需要往下执行，且往往if else两个{}中代码所占行数不多，也相当简洁，肯定不用滑动滚动条去看花括号中的代码。这里学到的是，如果我们不得不用else，那就让else写的相当好看，把互斥的代码写进去，公共的不要写进去。
unix编程艺术中写到一个编程哲学被大师们奉为圭臬——K I S S 原则（懒人原则）
大师们开玩笑说我们只是因为懒而去提升自己的编程匠艺，最好写一次代码就不再出bug，这个懒大有深意
希望能帮到还在写很多else，代码结构混乱的童鞋。
网友评论