本文讨论被间接代码毁掉的可阅读性。

作者 | Matthew Rocklin

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

我常常看到有些代码的作者为了抽象，而把细节放入某个外部函数中。请看下面的例子。

加入间接代码之前：

# main.pyif x.startswith("foo"):    do_something_with(x)

if x.startswith("foo"):    do_something_with(x)

加入间接代码之后：

# main.pyif is_foolike(x):    do_something_with(x)

if is_foolike(x):    do_something_with(x)

# utils.pydef is_foolike(x):    return x.startswith("foo")

def is_foolike(x):    return x.startswith("foo")

这种做法的理由可能包括：

• 如果代码重复多次，那么这种抽象可以让代码更紧凑；

• 如果代码重复多次，那么就应该找一个位置集中管理这段逻辑，以便将来可以集中修改；

• 这种抽象隐藏了与功能要点无关的细节，就像散文中的脚注；

• 这种抽象通过函数名称作为内联文档为一组操作命名；

• 感觉代码更干净，更抽象。

学校老师就是这么教我们的——找到一些功能，抽象出去，然后继续。

避免间接的情况

然而，这种添加间接代码的行为也需要付出代价。当其他人阅读这段代码时，他们需要在多个文件定义的多个函数之间跳转。这种非线性的阅读过程更加耗费阅读者的精力。

在写代码的过程中，加入这种间接代码并没有任何问题，写代码的人的脑海中建立了一个抽象模型，因此将这种抽象写入代码是有意义的，感觉很好。但是，当其他人需要快速检查和理解一段代码时，就会遇到大麻烦。这发生在两种重要的情况下：

1、在代码审查期间。当其他人需要在代码合并到主项目之前，检查代码是否合理。这些审查人员需要花费的时间大约是写代码的时间的十分之一。

2、将来的调试。如果代码中存在任何问题，那么将来完全陌生的开发人员将不得不查看这段代码，并搞清楚代码的内容。他们必须在几分钟内理解这段代码，并确定相关的内容。他们没有时间理解代码背后完整的思维过程，而间接的代码会大大减慢理解的过程。

与原来的开发过程相比，现代社区代码中的审查和调试往往是瓶颈。因此，我经常鼓励开发人员避免抽象，并将函数定义写在代码内部。

我们仍然应该使用函数

需要明确的是，我们有很多理由将复杂的逻辑分成多个函数，特别是面对重复代码的时候，或者某些重要的政策可能会在将来发生变化时。因此，我们需要找到一个平衡点。

我希望在大多数情况下，写代码的人能够意识到除了原作者之外，每个阅读代码的人都会感受到间接代码带来的附加成本。

原文：http://matthewrocklin.com/blog/work/2019/06/23/avoid-indirection

作者：Matthew Rocklin，维护与协调Python数字计算生态系统中的多个库，特别是有关高效和可扩展的计算。

本文为 CSDN 翻译，转载请注明来源出处。

【END】

 热 文 推 荐 

☞小鹏员工承认备份特斯拉源代码；Apple Watch 现漏洞；Python 3.7.4 发布 | 极客头条

☞JavaScript 的函数式编程与面向对象编程区别在哪？

如果微软开发了 Android，会有何不同？

我在阿里的十年：从 BI 到产品经理，曾被程序员踢翻桌子骂

☞Libra的Move编程语言到底是个啥? 美女程序员通读26页的白皮书后, 找出了这些精华… | 技术头条

☞文末送书啦！| Device Mapper，那些你不知道的Docker核心技术

☞BigBiGAN问世，“GAN父”都说酷的无监督表示学习模型有多优秀？

☞学好正态分布有多重要？

☞实测！华为鸿蒙比 Android系统快60%！

点击阅读原文，输入关键词，即可搜索您想要的 CSDN 文章。

你点的每个“在看”，我都认真当成了喜欢