程序员们，这些“坑”你熟悉吗？

严谨如程序员，时间久了还是会有一些"想当然"。不知不觉中就会掉进很多陷阱里。看看这些陷阱，你都中招了吗？

译文：

我对误解很感兴趣。以前我经常在酒吧里主持猜谜游戏（我们这里有的地方叫做“冷知识之夜”），参加过几次的人都知道，如果一道题看上去像是陷阱，那通常它就是陷阱。我的题目里有相当多的“似真似假”的题目，其中所有问题的答案都是假，但几乎没有任何人注意到这一点，因为每道题都是人们平常深信不疑的错误的事情。

等等，这跟编程有什么关系？别着急，继续读下去。

在Hacker News或Proggit上评论的程序员并不是从计算机行业随机选取的，而是这个行业中的精英部分。就像参加任何会议一样，参与评论的这些人都比一般程序员对编程更有热情。

然而，从许多评论中可以看出，许多很厉害的程序员也会有各种信仰和误解，这些信仰和误解虽然错得离谱，但却广为流传。下面是我收集的一些很有意思的误解，附有我的解释。

C语言就是快。

如果说哪个误解会招致差评、导致认知差异、甚至引起口水战？那很可能就是这一条了。

就像其他的误解一样，我对这一条完全不理解。

估计是因为我学C语言的那个时代，人们普遍认为C语言用于游戏编程等很慢，而汇编才是王道。或者是因为，程序都要编译成机器语言，而就像什么顺势疗法一样，汇编语言仿佛是水，能记住自己从哪儿来，从而使得CPU能执行得更快……于是就有了下一条误解。

垃圾回收语言就是慢。

这里说的垃圾回收指的是“跟踪式垃圾回收”。许多人都评论说，在真正的系统中编程时，跟踪是垃圾回收是多么不能忍。要是每条评论我能收一分钱的话，我现在就有好几块钱了。

我大概能理解这一条，因为四年前我也相信。

我还曾经相信后台会有小仙子自动帮我清理那些“明显”会导致程序变慢的代码。以后我会写一篇文章专门讲这个问题。

Emacs是个文本模式的程序。

每次有人说文本编辑器比不上IDE，就必然有人跳出来问，为啥非要用文本模式的编辑器。

我是个Emacs用户，我也不知道为啥他们都要用。类似地还有……

文本编辑器没办法也不应该拥有自动完成、查找定义等功能。

这一条通常会在讨论Emacs是终端程序的帖子里出现。通常还会伴随着一些人说IDE的上述功能是必要的。我也不用IDE编程，估计以后也不会。同样，我很少看到用编辑器用得很溜的人。

不记得多少次看到某人用vim打开一个文件，发现开错了，关掉vim，再打开另一个文件，再关掉……啊啊啊啊啊啊啊啊啊啊。

还有人“喜欢Eclipse”却不知道“查找定义”功能的……简直是奇迹。

由于C ABI是编程的通用语言，所以实现应该也用C语言。

在讨论二进制代码时C语言是真正的胶水语言。

这是有历史原因的，但不可否认在这方面C语言就是王者。但令我大跌眼镜的是，很多人把这句话理解为，如果API是C语言的，那么实现它的唯一语言就是C语言。也不想想Visual Studio的libc是用C++写的。

C和C++是同一种语言，真正的名字是C/C++。

而且没人把Objective C算进去（其实Objective C跟C++不一样，它实际上是C语言的超集），因为……啥原因呢？

C和C++有太多共通的地方，有时候当你想说一些适合两种语言的东西时，写成C/C++是有道理的。但许多时候人们并不是这样用……

在并发编程的容易性方面Rust是唯一的选择。

我估计所有使用Pony、D、Haskell、Erlang等语言的人都不明白这句话。Rust是不是比C++更安全？当然是，但这个标准也太低了。

我第一次用Rust时花了30分钟就死锁了。我感觉并不容易，或者应该说“不考虑数据冲突的话很容易”？反正是很容易上当.

内核只能用C语言。

显然Haiku和Redox被无视了，以及其他一切unikernel框架。

平台的字节序很重要。

这又是一条让我迷惑不解的理论。

我甚至都不知道为啥还有htons和ntohs这两个函数。完全搞不懂，而且更悲惨的是，我跟别人解释这个时，似乎他比我还明白。

我并不是说字节序不重要，而是说99.9%的情况下，人们认为它很重要，实际上却完全无所谓。我肯定会读一次IEEE浮点数的定义，但这并不意味着写任何程序都必须记住哪一部分才是尾数。

Haskell代码能通过编译就能跑！

嗯……不是的。

简单的语言能避免复杂性。

也称为“清扫地毯下面的尘土”迷信。

我并不明白这句话。我的意思是，一项任务的复杂度并不会因为使用了简单的语言而消失，甚至会变得更复杂。有许多负责搞笑的语言极其简单，但真用来写代码就简直是噩梦。

代码覆盖率是测试质量的标准。

我认为覆盖率很重要。我觉得，阅读一份漂亮的HTML覆盖率报告确实能够帮助书写高质量的软件。但我十分确信，追逐代码覆盖率的目标是有害的，而且毫无意义。下面是个很无聊的函数：

然后是测试套件：

100%的覆盖率。函数甚至连返回值都不对。好吧，其实应该assert点啥东西：

100%覆盖率。嗯……要不这样？

测试成功！当然，别给y传0……

应该测量测试覆盖率，阅读报告，然后决定下一步该做什么。之前我也写过着跟问题。

C能最接近地映射到硬件。

如果“硬件”的意思是PDP11或微型嵌入式设备，那么没错。但写内核不能只用C不用汇编是有理由的。

而且还有这一堆东西：SIMD，多ＣＰＵ核心，缓存层次结构，缓存管线，内存预取，乱序执行，等等。至少现在有原子性了。

我不知道人们给量子计算机写代码的时候还会不会说C最接近硬件。听起来似乎很傻，但我还见过更傻的。

另外，Lisp机器从来没存在过，FPGA/GPA也不是硬件（别忘了Poe定律！Poe定律：只要不明确表明是讽刺，那么不管讽刺得多么夸张，总会有人信以为真）。

做某件事只能用某个语言。

不管你说的某件事是啥，Lisp估计都能做。

原文：https://atilanevesoncode.wordpress.com/2018/06/12/myths-programmers-believe/

作者：atilaneves

免费资料