程序员们,这些“坑”你熟悉吗?

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

译文:

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

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

在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,多CPU核心,缓存层次结构,缓存管线,内存预取,乱序执行,等等。至少现在有原子性了。

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

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

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

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

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

作者:atilaneves

免费资料

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180908A0HW2Y00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券