更简洁,更优雅,但是很难看懂的代码

更简洁,更优雅,但是很难看懂的代码

作者:BlogUpdater |  时间:2022-03-30 |  浏览:143 |  评论已关闭 条评论

似乎有些人将我几个月前的一篇文章的标题”更干净、更优雅、更错误”解释为对异常使用的一则引用。 (请看参考书目参考[35];请注意,引用者甚至将我的文章的标题改了!)

如你所看到的,今天文章的标题是对我从一本书中引用的一段代码,这本书的作者声称他提供的代码”更干净、更优雅”。 我指出,这段代码片段不仅更干净、更优雅,而且也是错误的。

你可以编写正确的基于异常的程序。
但是我得提醒你了:这不是一件容易的事情。

换句话说,某件事很难,但不意味着不应该做这件事。

下面我们看一个例子:

不管使用哪一种错误模型,编写一段坏代码都很容易。

编写一段基于错误代码的代码很困难,因为你需要检查每个调用的返回值,并思考如果错误发生时,应该如何处理。

而编写一段基于异常的好代码更加困难,因为你需要检查每一行代码(别吃惊,每一行代码),并思考这段代码是否有可能抛出一个异常,以及如何处理它。(在C++中还算好,C++异常只会在执行的某些特定阶段被抛出,而在C#中,异常可能在任意时刻被抛出)

但是,这也不是什么大事儿。就像我上面所说的,一件事很苦难,不意味着我们就不应该做这件事。就比如,驱动程序开发起来很难,但是人们还是继续开发它们,这是好事。

下面是另外一张表格:

我举一个使用了错误代码的代码片段,你可以试试判断它到底是好代码,还是坏代码。

这段代码很显然是坏代码。所有函数调用的的返回值都没有检查,当人们急于完成一段功能时可能会写出这样的代码,然后在下次版本的迭代中不断优化和完善。
而且我们很容易知道代码的哪些地方需要完善,很直接。

下面是另外一个版本:

这段代码依然是错误的,但我们可以明显的看出来,代码的作者还是很想改善它。这就是我为什么说它是”没那么坏的代码”。

下面我们来看看一段基于异常模型的代码:

(这是一篇关于任务栏通知图标的文章中的程序的实际代码,只是在原始版本的基础上做 了一点小改变)

下面是可能经过完善之后的版本:

很微妙,对吧?

对于错误代码模型的代码来说,很容易判断代码是好代码还是坏代码:好代码会做错误代码检查,而坏代码不会。诚然,很难判断针对错误代码的处理方式是否是合适的,但是至少你可以看出来代码的好坏来。(可能也并不是那么好,但是绝对不差)

而对于使用异常模型的代码来说,就很难看出来好坏了。

当我编写基于异常模型的代码的时候,我没有机会先编写一段坏代码然后慢慢优化它。因为如果这样做了,我就无法再找出坏代码出来,因为在这种错误模型下,好代码和坏代码之间几乎没有什么变化。

我的想法不是说异常是不好的东西。而是,异常代码实在是太难编写了,我还没有聪明到可以完全掌控它们。(包括某些技术书籍的作者,即使他们在书中教你如何使用异常编程!)

是的,有类似于 RAII 和事务这样的编程模型,但你很少看到使用其中任何一种的例子代码。

总结
在开发TopomelBox的过程中,我处于比较纠结的状态:有时候我觉得使用异常好,有时候我觉得使用错误代码好。
到底用哪个嘛!(我全都要?)

最后
Raymond Chen的《The Old New Thing》是我非常喜欢的博客之一,里面有很多关于Windows的小知识,对于广大Windows平台开发者来说,确实十分有帮助。
本文来自:《Cleaner, more elegant, and harder to recognize》

最近我写了个东西
正如你们所知道的,拓扑梅尔智慧办公平台(Topomel Box)是一款绿色软件,主要面向经常使用电脑的朋友。它提供了各种提升办公效率的小功能,同时操作上尽可能地简单方便。
我想:你值得拥有。

评论已关闭。