点击上方“CSDN”，选择“置顶公众号”

关键时刻，第一时间送达！

以严谨著称的程序员们似乎与“迷信”一词毫无关系。不过事实上，很多程序员都存在一些根深蒂固的编程误解，即使是 Hacker News 或 Proggit 上的很多程序员精英也不能避免。

以下为译文：

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

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

在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覆盖率报告确实能够帮助书写高质量的软件。但我十分确信，追逐代码覆盖率的目标是有害的，而且毫无意义。下面是个很无聊的函数：

int divide(int x, int y) { return x + y }

然后是测试套件：

TEST(divide) { divide(4, 2); }

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

TEST(divide) {     assert(divide(4, 2) == 2);     assert(divide(6, 3) == 2);}int divide(int x, int y) { return 2; }

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

TEST(divide) {     assert(divide(4, 2) == 2);     assert(divide(9, 3) == 3);}int divide(int x, int y) { return x / y; }

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

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

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

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

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

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

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

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

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

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

作者：atilaneves

译者：弯月，责编：郭芮

  征稿啦！

CSDN 公众号秉持着「与千万技术人共成长」理念，不仅以「极客头条」、「畅言」栏目在第一时间以技术人的独特视角描述技术人关心的行业焦点事件，更有「技术头条」专栏，深度解读行业内的热门技术与场景应用，让所有的开发者紧跟技术潮流，保持警醒的技术嗅觉，对行业趋势、技术有更为全面的认知。
如果你有优质的文章，或是行业热点事件、技术趋势的真知灼见，或是深度的应用实践、场景方案等的新见解，欢迎联系 CSDN 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。

————— 推荐阅读 —————

点击图片即可阅读