越“聪明”的代码，越是“一次性” 全球播资讯

2023-06-05 12:56:01 来源：东方资讯

大多数程序员，面对复杂问题却能写出精简代码时，总会觉得颇有成就感。但本文作者指出：看似越精简的“聪明”代码，其可读性越低，越是得不偿失。

原文链接：https://www.joshwcomeau.com/career/clever-code-considered-harmful/

(相关资料图)

作者 | Josh Comeau

译者 | 弯月责编| 郑丽媛

出品 | CSDN（ID：CSDNnews）

不可否认，遇到难题能想到巧妙的解决方案会让人很有成就感。例如，挑战自己使用递归而不是迭代，或者创建优雅的级联抽象层以确保代码永远不会重复，你一定会感到很高兴。

对于这类编程，我最喜欢的一个资源是Project Euler（地址：https://projecteuler.net/）。

Project Euler 是一个基于高等数学的挑战库，旨在通过软件解决问题，要求程序在 2004 年左右的硬件上运行时间不超过 1 分钟。这意味着，你不能靠蛮力解决问题，必须想出一个更聪明的解决方案。

下面是一个例子：

问题 58：螺旋质数

从 1 开始，按如下方式逆时针旋转，形成一个边长为 7 的正方形螺旋。

有趣的是，奇数的平方数都位于右下对角线；更有趣的是，位于两条对角线上的 13 个数字中有 8 个是质数，总体占比为：8/13=62%。

如果在上面的螺旋之上再加一层，就会形成一个边长为 9 的正方形螺旋。如果继续这个过程，那么当正方形螺线的边长为多少时，两条对角线上的质数百分比将首次低于 10%？

解决这个问题后，你还可以查看其他人共享的解决方案。你会感到很惊讶：哇！居然有人能想出如此简洁、如此聪明的解决方案？！

下面就是一个用户使用 Haskell 编写的解决方法：pe58 = nwherea p q = scanl (+) p $ iterate (+ 8) q b = [[x,y,z] | (x,(y,z)) <- zip(a 310) $ zip(a 512) (a 714)] c= zip(scanl1 (+) . map(length . filterisPrime) $ b) (iterate (+ 4) 5) [(n, _)] = take 1$ dropWhile (\( _,(a,b)) ->10*a >b) $ zip[ 3, 5..] c

下面是一个用户使用 J 语言编写的代码：gt; :-:>:1i.~ 0. 1>}.(>:i.$n)%~+ /\n=. isprime +/\ 1, 4#2*>:i.14000

显然，用如此少的代码解决如此困难的问题需要大量技巧。如果我能够写出这样的解决方案，我会为自己感到高兴，但我的解决方案总是又长又不优雅。

不过，日常工作中一般不会出现这样的代码——这些代码只是为了娱乐，编写这样的代码多数是为了凸显自己的聪明、吓唬其他人或锻炼大脑。

上述这类问题的代码，你永远也不会阅读第二次，因为它们都是一次性的，我们也不会交给其他人来维护，这与我们日常编写代码的环境不同。

实习生测试

在谈论日常编写的代码时，我会按照下面这个标准来要求：初级开发人员、或者说刚开始职业生涯的人，是否能够理解这段代码？

所以对于共享的代码库而言，好代码就是简单的代码，不需要任何花里胡哨，便于向新手解释基本概念的代码。

例如几年前，我曾接到一个任务，是审查包含以下函数的拉取请求：constextractDataFromResponse = ( response) =>{ const[Component, props] = response; constresultsEntries = Object.entries({ Component, props }); constassignIfValueTruthy = ( o, [k, v]) =>(v ? { ...o, [k]: v }: o);returnresultsEntries.reduce(assignIfValueTruthy, {}); }

我给出的建议是，按照下面这样重写：constextractDataFromResponse = ( response) =>{ const[Component, props] = response; constoutput = {}; if(Component) { output.Component = Component;}if(props) { output.props = props;}returnoutput; }

平心而论，原始版本确实有很多优点：

▶ 代码量更少（只有 4 个语句，而第二个版本中有 7 个语句）；

▶ 没有重复（在第二个版本中，两个 if 语句的作用基本相同）；

▶ 没有修改任何变量；

▶ 更具可扩展性：重写后可轻松处理 10 个字段，而不止 2 个。

但是，原始版本更难理解——我不得不浪费大量脑细胞来理解这些代码究竟在干什么，对于许多初级开发人员而言，应该也无法很好地理解。

在我看来，函数式版本的可读性成本太高了，得不偿失。

为什么可读性如此重要？

为了说明我认为可读性是好代码的一个重要属性，下面我们来看看流行的开源库 lodash。

lodash 是一个非常流行的库，每周仅通过 NPM 的下载量就超过 2600 万次，Github 上的 Star 数更是超过了 4.2 万个。然而，有一个很奇怪的地方是：这个库未解决的问题始终不会超过 10 个。

尽管我们一直都提倡 Inbox Zero（收件箱归零），但热门项目的问题永远不会归零。但 lodash 的未解决问题经常为零，并且多年来一直如此。

有个主要原因可能是主作者 John-David Dalton 是一位热情的维护者，他花费了大量时间对问题进行分类。但我觉得，无论是任何人，就算是超人，都无法做到让如此热门的一个库的问题数归零——直到在多年前，我在播客上听到 John-David Dalton谈论管理这类项目的关键是，如何鼓励很多人为代码库做贡献。

他的方法之一是将代码保持在非常基础的水平，使用简单、基本的结构，确保贡献者无论经验深浅都能理解代码并为其做出贡献。我记得，John-David Dalton 提到他们更喜欢 if/else，而不是三元运算符，因为很少有人有使用三元运算符的经验。换句话来说，如果你的目标是保持代码简单易懂，那么用三元运算符的表达方式就是有害的。

如果你正在构建开源工具，那么记住这一点很重要；如果你正在与其他人一起开发生产代码库，那么这一点就尤为重要，特别是当队友的经验不如你时。

bug数与代码长度

你听过下面这句话吗？

“更少的代码意味着更少的错误隐藏空间。”

这句话的意思是，代码要越短越好，因为这样更容易发现错误，而每多敲一个字符，都会增加出错的可能性。

对于拼写错误这类的 bug，上述论点固然没错，但拼写错误往往很容易被发现和修复。真正麻烦的 bug 是由代码过于复杂而引发的，开发人员遇到这类 bug 就好像拿到烫手山芋，恨不得立即甩锅给别人。

在调试问题时，你必须全神贯注，仔细理解每一行代码。当你创建一个抽象来减少重复（所谓“DRY 原则”，Don"t Repeat Yourself，不要重复你自己）时，无形中就添加了一个间接层，理解起来也就多了一重障碍。思维模型越难解释每一个边缘情况和可能的状态，就越难诊断出问题的关键所在。

“每个人都知道调试比写程序要难一倍。所以，如果你在编写代码时机关算尽，那么将来要如何调试呢？”

—— Brian Kernighan，《The Elements of Programming Style》

抽象的成本

如果目标是降低复杂性，而抽象增加了复杂性，那么我们是否应该完全废除抽象呢？并不是。因为抽象无处不在：循环是抽象，函数是抽象，编程语言本身就是对机器代码的抽象，而机器代码本身则是晶体管的抽象。

所以说，一切都是抽象。关键在于，我们需要权衡抽象的成本与收益。