@程序员，这些编程陷阱你中招了吗？
点击上方“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 投稿，联系方式：微信（guorui_1118，请备注投稿+姓名+公司职位），邮箱（guorui@csdn.net）。
————— 推荐阅读 —————
点击图片即可阅读