编程时来点小叛逆 是不是超爱这 10 种坏习惯？

这些事儿我们都干过：比如趁妈妈不注意赶紧偷吃一块饼干；比如开车过急转弯不减速。当然，编程的时候我们也爱来点小叛逆。

我们对好的编程规则不屑一顾，打出来的代码非常糟糕——可也就这么对付过去了，并没有编程之神用闪电惩罚我，我们的电脑也没有爆炸。实际上，我们的代码已编译完成并交付使用，客户也似乎很满意。

那是因为糟糕的代码并不像摸电门或者摸老虎屁股那样后果严重，大多数时候这些代码都能用。编程规则往往只是指引或对编程风格的建议，并不会出现不遵守代码就会完蛋的铁律。当然，你的代码可能会被同行嘲笑，甚至是“公开处刑“。但违反约定也是一种有点刺激的反叛行为；这种叛逆行为往往是产生优秀代码的一种途径，哪怕你不是故意为之。

让事情变得更复杂的是，有时打破规则才是更好的选择。这样的代码没准儿会更清晰，甚至可以更快更简洁。规则往往太过宽泛，熟练的程序员可以为了改进代码而打破常规。有时候用自己的方式编程是很有意义的，不过这一条可别跟你的老板说。

下面是 10 条规则列表，其中也有被认为是不可逾越的规则，但我们很多人经常会打破这些规则，而且结果还很不错。

TOP1：粘贴复制

在学生时代，我们都知道抄袭是不对的。但在工作中，这方面的规则还很模糊。虽然有些代码块是不能盗用的——不要把专有代码拷贝到你的堆栈中，尤其是这些代码有标记版权信息。这种时候你应该编写自己的版本，老板付你薪水就是要做正事的。

但是当原始创作者想要共享代码时，问题就变得复杂了。这些共享代码也许放到了某个在线编程论坛上，也许它们是带有许可证（BSD，MIT）的开放源代码，允许使用一到三个函数。你使用这些共享代码是没有问题的，而且你上班是为了解决问题，而不是重新发明轮子。

大多数情况下，复制代码的优势非常明显，小心对待的话问题也不大。至少那些从靠谱的来源获得的代码已经被大致“检查“过了。

问题的复杂之处在于，这些共享代码是否存在一些未发现的错误，代码的用途或底层数据是否存在一些特别的假设。也许你的代码混入了空指针，而原始代码从未检查过。如果你能解决这些问题，那么就可以理解为你的老板得到了两位程序员共同努力的成果。这就是某种形式的结对编程，而且用不着什么高大上的办公桌。

TOP2：非函数式代码

在过去十年间，函数范式愈加流行。喜欢用嵌套函数调用来构建程序的人们引用了很多研究成果。这些研究表明，与旧式的变量和循环相比，函数式编程代码更安全，错误更少，而且可以随程序员的喜好任意组合在一起。粉丝们十分追捧函数式编程，还会在代码审查和拉取请求中诋毁非函数式方法。关于这种方法的优势，他们的观点其实并没有错。

但有时你需要的仅仅是一卷胶带而已。精心设计并细心计划的代码需要花费很多时间，不仅需要花费时间想象，还需要构建和之后导航的时间。这些都增加了复杂性，并且会花费很多的时间与精力。开发漂亮的函数式代码需要提前做计划，还要确保所有数据都通过正确的途径传递。有时找出并更改变量会简单得多，可能再加个注释说明一下就够了。就算要在注释中为之后的程序员致以冗长而难懂的歉意，也比重新设计整个系统，把它扳回正轨上要省事得多。

不良的编程习惯第 3 位：非标准间距

软件中的大多数空格都不会影响程序的性能。除少数使用间距指示代码块的语言（如 Python）外，大多数空格对程序行为的影响为零。尽管如此，仍然有一些得了强迫症的程序员会数空格，并坚持认为它们很重要。曾有这样一位程序员以最严肃的口吻告诉我的老板，说我正在写“非标准代码”，还说他一眼就看出来了。我的错咯？因为我没在等号的两侧放置空格，违反了 ESLint space-infix-ops 规则。

有时候你只要操心那些更深层的内容就行了，谁管什么空格的位置。也许你担心数据库过载，也许你担心空指针可能会让你的代码崩溃。一套代码中，几乎所有的部分都比空格更重要，就算那些喜欢走形式的标准委员会写出来一大堆规则来限制这些空格或制表符的位置，那又如何呢。

令人欣喜的是，网上可以找到一些很好用的工具来自动重新格式化你的代码，让你的代码遵守所有精心定义的 linting 规则。人类不应该在这种事情上浪费时间和脑细胞。如果这些规则这么重要，我们就应该用工具来解决这些问题。

不良的编程习惯第 4 位：使用 goto

禁止使用 goto 的规则可以追溯到许多结构化编程工具还没有出现的时代。如果程序员想创建一个循环或跳转到另一个例程，则需要键入 GOTO，后跟一个行号。多年之后，编译器团队开始允许程序员使用字符串标签来代替行号。当时这被认为是一项热门的新特性。

有的人把这样做法的结果称为“意大利面条式代码”。以后没人能读懂你的代码，没人搞得清楚执行路径。那会是一团混乱的线程，永远缠结在一起。Edsger Dijkstra 以题为“我们认为 Goto 声明是有害的”的一篇文章禁止大家使用这个命令。

但是绝对分支并不是问题所在，问题在于它产生的那堆纠缠的结果。一般来说，精心设计的 break 或 return 能提供有关该位置的代码执行情况的非常清晰的陈述。有时，将 goto 添加到一个 case 语句中所生成的东西，比级联 if-then-else 块的，结构更正确的列表理解起来更容易。

也有反例。苹果 SSL 堆栈中的“goto fail”安全漏洞就是一个很好的例子。但是，如果我们谨慎地避免 case 语句和循环中出现的一些问题，我们就可以插入很好用的绝对跳转，使代码读者更容易理解正在发生的事情。有时我们可以放一个 break 或 return，不仅更简洁，而且大家读起来更愉快——当然那些讨厌 goto 的人们除外

不良的编程习惯第 5 位：不声明类型

热爱类型化语言的人们有他们的理由。当我们为每个变量的数据类型添加清晰的声明时，我们会编写更好，错误更少的代码。花点时间来阐明类型，就可以帮助编译器在代码开始运行之前标记出愚蠢的错误。这可能会很痛苦，但也会有回报。这是一种编程的笨办法，就是为了避免错误。

时代变了。许多较新的编译器已经足够聪明了，它们可以在查看代码时推断出类型。它们可以在代码中前后移动，最后确认变量应该是 string 或 int，抑或是其他类型。而且，如果推断出来的这些类型没法对齐，则编译器会给出错误标志。它们不需要我们再类型化变量了。

换句话说，我们可以省略一些最简单的声明，然后就能轻松节省一些时间了。代码变得更简洁，代码读者也往往能猜出 for 循环中名为 i 的变量是一个整数。

不良的编程习惯第 6 位：溜溜球代码

程序员喜欢将其称为“yo-yo 代码”。首先，这些值将存储为字符串，然后将它们解析为整数，接下来将它们转换回字符串。这种方法效率极低。你几乎能感受到一大堆额外负载让 CPU 不堪重负的样子。能快速编写代码的聪明程序员会调整自己的代码架构，以最大程度地减少转换。因为他们安排好了计划，他们的代码也能跑得更快。

但不管你信不信，有时溜溜球代码也是有意义的。有时，你要用到一个疯狂的库，它在自己的黑匣子里会搞定一大堆智能操作。有时老板花了很多钱，请好多天才做出来这么一个库。如果这个库需要字符串形式的数据，那么你就得给它字符串，哪怕你最近刚把数据转换为整数也得再转回去。

当然，你可以重写所有代码以最大程度地减少转换，但这会花费一些时间。有时，代码多运行一分钟、一小时、一天甚至一周也是可以接受的，因为重写代码会花费更多时间。有时候，增加技术债务要比重新建立一笔技术债的成本更低些。

有时这种库里面不是专有代码，而是你很久以前编写的代码。有时，转换一次数据要比重写该库中的所有内容更省事。这种时候你就可以编写悠悠球代码了，不要怕，我们都遇到过这种事情。

不良的编程习惯第 7 位：编写自己的数据结构

有一条标准规则是，程序员在大二学完数据结构课程后，再也不要编写用于存储数据的代码了。已经有人编写过了我们所需要的所有数据结构，并且他们的代码经过了多年的测试和重新测试。这些结构与语言打包在一起，还可能是免费的。你自己写的代码只会是一堆错误。

但有的时候数据结构库的速度有点缓慢。有时候我们被迫使用的标准结构并不适合我们自己的代码。有时，库会要求我们在使用它的结构之前重新配置数据。有时，这些库带有笨重的保护，还有一些诸如线程锁定之类的特性，而我们的代码并不需要它们。

发生这种情况时就该编写我们自己的数据结构了。有时我们自己的结构会快很多，还可能让我们的代码更整洁，因为我们不需要一大堆额外的代码来重新精确地格式化数据。

不良的编程习惯第 8 位：老式循环

很久以前，创建 C 语言的某人想将所有抽象可能性封装在一个简单的构造中。这个构造开始时要做一些事情，每次循环都要做一些事情，所有事情都完成时还有一些方法来提示我们。当时，这似乎是一种拥有无限可能性的完美语法。

此一时彼一时。如今一些现代评论者只看到了其中的麻烦。发生的事情太多了。所有这些可能性既可能向善也可能作恶。这种构造让阅读和理解代码变得非常困难。他们喜欢更加函数式的的范式，其中没有循环，只有应用到列表的函数，还有映射到某些数据的计算模板。

有时无循环方法更简洁，尤其是当我们只有一个简单的函数和一个数组的时候。但还有些时候，老式的循环要简单得多，因为它可以做更多事情。例如，当你找到第一个匹配项后就立刻停止搜索，这样的代码就简单得多。

此外，要对数据执行多项操作时，映射函数会要求更严格的编码。假设你要对每个数字取绝对值，然后取平方根，最快的方案是先映射第一个函数，然后映射第二个函数，将数据循环两次。

不良的编程习惯第 9 位：在中间打破循环

从有一天开始，一个规则制定小组宣布每个循环都应该有一个“不变项”，就是一个在整个循环中都为真的逻辑语句。当不变量不再为真时，循环就结束了。这是处理复杂循环的好方法，但会带来一些令人抓狂的约束，例如禁止我们在循环中间使用 return 或 break。这条规则是禁止 goto 语句规则的子集。

这个理论很不错，但它通常会导致代码变得更复杂。考虑以下这种简单的情况，其中会扫描一个数组，找出通过测试的一个条目：

while (i<a.length){   ...   if (test(a[i]) then return a[i];   ...}

喜欢循环不变项的人们宁愿我们添加另一个布尔变量，将其称为 notFound，然后这样用它：

while ((notFound) && (i<a.length){   ...   if (test(a[i])) then notFound=false;   ...}

如果这个布尔名称取得很合适，那就会是一段自我注释得很好的代码。它可以让大家理解起来更容易。但这也增加了复杂性。这还意味着要分配另一个局部变量并阻塞一个寄存器，编译器可能没那么聪明，没法修复这个错误。

有时 goto 或 jump 会更简洁。

不良的编程习惯第 10 位：重新定义运算符和函数

一些最有趣的语言会让你绕一些大弯子，比如说重新定义看起来应该是常量的元素值。拿 Python 来说，至少在 2.7 版及更低版本中，它允许你键入 TRUE=FALSE。这不会引发某种逻辑崩溃，也不会导致宇宙的终结；它只是交换了 TRUE 和 FALSE 的含义。你还可以使用 C 预处理器和其他一些语言来玩这种危险的游戏。还有一些语言允许你重新定义加号之类的运算符。

有时候，在一大段代码中重新定义一个或一些所谓常量，结果效率会更高。有时，老板会希望代码执行完全不同的操作。当然，你可以检查代码，逐一更改对应的部分，也可以干脆重新定义现实来节省时间。别人会觉得你是天才。用不着重写庞大的库，只需翻转一下即可。

这里也许应该划一条底线。无论这种做法多有意思，看起来多聪明，你都不应该在家里做实验。这太危险了——我是认真的。

相关链接

[1]ESLint space-infix-ops 规则：https://eslint.org/docs/rules/space-infix-ops

[2]《我们认为 Goto 声明是有害的》：http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_Harmful.html

[3]“goto fail”安全漏洞：https://dwheeler.com/essays/apple-goto-fail.html

作者介绍：

Peter Wayner 是 InfoWorld 的特约编辑，并撰写了 16 本书，涉及各种主题，包括开源软件、自动驾驶汽车、增强隐私的计算、数字交易和隐写术等。

原文链接：

https://www.infoworld.com/article/2992566/10-bad-programming-habits-we-secretly-love.html