为什么程序员动不动拽英文单词不是装 B

[cheka]

看到我厂另一位同事写的“为什么程序员英文要好” https://www.v2ex.com/t/239995 特来呼应一下。

（部分内容曾经发在知乎 http://www.zhihu.com/question/23581913/answer/25023096 ）

类似以下的对话几乎每天都会发生在我们公司——我们公司不是外企，只是民营小企业，也没有国际友人。

“用户报了一个 bug ，我提个 issue 给你”

“好，我 check 下。”

“这个 bug 我 fix 了，代码已经 commit 。”

“那我们下周升级这个 App 。”

这四句话里，有 6 个英文单词，我给它们做个归类，分析下为什么我们会不自觉地选用英文而非相应的中文单词。

首先， bug 这个词已经深入人心，专指计算机软件产生的问题，不仅是专业的工程师用这个词，很多用户也会直接说这个程序有 bug 我用不了。这个从早期计算机教育里就引入的英文单词已经用来专指软件的逻辑故障，比任何单一中文词汇都更加准确；譬如如果改说程序出了故障，大部分人很可能第一反应是硬件问题，如果说程序有了问题，又无法立刻表明究竟是使用产生问题还是程序本身问题。

再看 issue, commit 这两个词，中文可以翻译为“工单”和“提交”，为什么我们要用英文呢，因为我们用的代码和问题管理软件里用的就是这两个词，所以对一个工程师说我给了你一个 issue ，那么他第一反应就会打开管理软件去查看，说的人和听的人脑子里都不用翻译转换。当然，如果用的软件是中文的话，我相信我们肯定会用“工单”而非 issue ，总之怎么省事怎么来。

再看 check, fix ，还有 App ，在中文里是有相对明确的对应词汇的，分别是“检查”，“修复”，还有“应用”。实际上我们也确实有时候会用对应的中文词，但是用英文更多，为什么呢？因为这几个英文词念起来更省力啊。

所以深究起来，想要用语言口头表达一个概念，以及想要理解自己听到的一个概念，都是要付出成本的，前者会涉及到词汇是否好念，是不是能够第一时间想到（从概念转换到词汇），后者会关系词汇是不是清晰（同音字 /词就很讨厌），是不是能迅速理解（从词汇转换到概念）。

在语言学里有一条著名的经验法则, 由哈佛语言学家 Zipf 提出并以他的名字命名，也就是 Zipf 定律。 Zipf 发现，如果把一种语言中的所有的词按照词频从大到小排序，并记录它们的排列位置，那么一个词的词频 f ，和它的位置 r ，近似满足如下关系：

f*r=k 其中 k 是一个常数。

掩藏在这公式背后的意思是，对于同一个概念，说话者期望选择一个出现频率很高，但是词义较含糊的词来表达，而听者则希望接受到一个出现频率很低，相应更精确的词汇。极端情况下，说话者巴不得只用一个词就能表达天下所有的意思，而听者则最好是一个萝卜一个坑，一个概念只有一个词相对应。总之双方都指着对方多担待，自己省点事儿。 Zipf 将此称为最省力原则(Principle of least effort).

对应这个原则的 Zipf 定律就是反映了说者和听者两者间讨价还价最后的折衷，即只有相当少的一些词能够表达很多语义，相应具有很高的出现频率；而绝大多数的词则能较准确的表达特定意思，也就只有较少的出现频率。

虽然 Zipf 定律针对的是同一种语言内部，但是在全球化的今天，很多英文词汇已经因为指向明确（因为很多概念首先来自英文，并且在其他语言还没来得及翻译的时候就已经广泛传播），同时也好念，从而符合最省力原则，在口头交流中被双方接受。


反过来说，如果我和一个非软件行业的人解释我们的工作，我基本不可能用任何英文（当然 bug 这个词例外），因为那时候我很清楚光自己说得爽不行，对方听不懂一问再问更麻烦，不如一开始就用中文。


所以说当我们一群码农在内部交流时不停冒英文，真的只是偷懒，而不是装 B 。

非 IT 行业里，很多情况也类似，很多英文术语会直接对应该领域中某个流程中的特定环节，提高沟通效率。


总之，这些单词就是这个行业的黑话。

另外，传说计算机开发中有两大最困难问题：更新缓存，以及变量命名。英文水平高一些，对于变量命名是非常有帮助的，一个不准确或者含糊的名字，不仅会给阅读者（甚至包括起名字的本人）带来歧义，未来还会妨碍新的命名，实际对程序是一种污染。

我们自己遇到过一个实际例子，打卡被命名为 checkin ，当时虽然感觉不是很准，但是将就用了；等到我们策划签到功能时，发现签到的英文就是 check in ，那怎么办，要改的话，不仅后端代码里有，各种对外 API 里也有，意味着所有移动客户端都要改，还要照顾那些不升级的老客户端；可是不改，就要想一个新名字，可这个不准确的新名字一方面用来别扭，另一方面还可能造成未来同样麻烦。

总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文，再翻译成中文。虽然一开始有人觉得浪费时间，但是逐渐大家还是接受了，好处是从工单描述，到变量，再到注释，都能尽可能维持一致性。

我们曾经拿托福阅读题给公司里所有员工都做过一次测试，工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的，还有几个满分。

[ffffwh]

“小 x 啊，下次变基了再提交代码”

[Delbert]

总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文，再翻译成中文。

唔，长叹……

[binux]

> “好，我 check 下。”

"我们中文" 一般说，「好，我查下」

> “这个 bug 我 fix 了，代码已经 commit 。”

"我们中文" 一般说，「这个 bug 我修了，代码已经提了」

> 再看 check, fix ，还有 App ，在中文里是有相对明确的对应词汇的，分别是“检查”，“修复”，还有“应用”。实际上我们也确实有时候会用对应的中文词，但是用英文更多，为什么呢？因为这几个英文词念起来更省力啊。

"我们中文" 不知道是不是比你们更省力呢？

[crisfun]

那么你要不要打算说下中国人写的主要面向中国开发人员，而且特别面向中国用户的程序从一开始到最终界面都用英文的合理性？


贵司既然这么能折腾工程师团队，请问对解决几百年都没改变的 Bug 有过帮助吗，对用户学好英语有比工程师中文更多优势吗？

[cheka]

@binux 你怎么说 git 里的 push 和 pull 呢，推和拉吗？

还是那句话，并非说中文无法表达，而是很多概念在中文有一致的翻译之前就已经得到应用，大家约定俗成的用英文了，这时候用中文翻译反而可能造成沟通不畅。你说拉代码，那我平常说拽代码怎么办？而用 pull 都明白。

[d7101120120]

像是 bug 找不到合适的中文词翻译，亦或者是在特定环境下的英文，如果说连普通的名词动词都要用英文表达，还真的不如直接使用全英文。

当然我也只是说说，实际怎么使用还是个人自由。

[crisfun]

@cheka 奇怪了， 你就确定你当真能因为以前的英文明白 git 里面的 push pull ？
还不是只有在额外的说明以后才能理解这里的指代。

那么问题来了，请你们摸着良心

你们理解 push pull 时候有用过它的对应中文意义与中文意义对应的“理解“给你的知觉吗？

既然英文都能额外解释理解 push pull 的意义，中文怎么就不行？

再说，你们是传说中的小团队，你打算因为一个词你们不能主导全球中文对它的翻译，就以为自己不能使用翻译的词汇。

[binux]

@cheka 「我代码更新了」「你更新下」，"我们中文" 没有那么弱。。

[LioMore]

「代码我已经通过分布式版本管理工具提交了，等做好下一个工单改好我就推送到主分支」
如果有人这么和我说话，我真的会觉得他在装逼

[lincanbin]

如果你身边有人这么说，总的来说，是你的朋友圈子出了问题，应该反思自己。

[crisfun]

其实我差点想说，你们用中文写变量名不就完了，你自己都描述你们是取的 英文变量名 check in ，结果另外一个东西，在中文里面倒是很大的区别，偏偏英文上又要和 checkin 重合。

那么你就干脆用中文，好认又好记，不会存在这不应该存在的问题。

[cheka]

@crisfun 我再强调一遍，没有任何贬低中文表达能力的意思，这个例子是说 git 在工程界大范围使用的时候，很多术语在中文里还没有一致的翻译，相关的中文书籍很可能有不同的翻法，导致对应读者脑子里就有不同的中文说法，这时候用中文就可能造成误解（把中文换乘其他语言也一样），而直接用英文术语就可以避免这个问题。

[loratadine]

轮完 4A 腔又来轮程序员了，下一个行业是什么？

[BROWNURSIDAE]

@crisfun 因为他们要面向世界编程

[crisfun]

@cheka 你说的 git 体系里面的词汇，即便可以说， git 这东西真奇怪不好翻译，那么其他词汇呢。
第二来说，我也再说，你们不需要其他人明白，你们自己明白就行。 你不需要全球一致的翻译。
再额外来说，你以为大家的翻译会差异非常大，结果多数词汇翻译的差异都不会那么大。

[crisfun]

@BROWNURSIDAE 那确实是，假装自己团队有外国人，假装团队都是英语大拿用外语比用母语好，假装自己很在意用户感受。

[vivianalive]

在国外似乎么这个问题，能把 push 说成推是件很有趣的事情。

[rwalle]

为什么总见到这种无聊的话题。。。

[Elethom]

「工單」是「 ticket 」，「 issue 」是「問題」。我讀書少你別騙我。
就這英語水平還是閉嘴吧。

[d8]

软文真的不错

[20015jjw]

并不装逼啊... DFS 和 SCC 难道还要深度优先搜索和强力连接组件么 hhhhh

[cheka]

@Elethom 我们内部用 GitLab ，和 Github 一样， issue 实际上翻译成工单更合适。

[6IbA2bj5ip3tK49j]

@LioMore
「代码我已经提交了，等下一个工单改好我就推送到主分支」
我中文一般是这么说的。
不知道你英语怎么说。

[cuebyte]

不明白不使用英文是如何产生优越感的，楼上诸位把常用单词翻译了就觉得自己胸前的红领巾更鲜艳了吗吗？这样的话不如写个插件汉化 github 好了。

对了，在交流超文本标记语言，层叠样式表，爪哇脚本，蟒蛇，红宝石，超文本预处理器（拍黄片）的时候，各种关键字也请替换上中文，比如循环，如果 /否则，开关 /情况。

[cheka]

@crisfun 奇怪，好端端说个方法学问题，怎么开始诛心“假装团队外语比母语好了”，我就是说下我们公司是这么做的，你觉得是瞎胡闹也罢，我也不争辩了。

[binux]

在特指的时候用英文并没有什么问题，比如 git 在说 push 和 pull 的时候（更常见的如 rebase ），特指这个操作。和「更新一下」做出区别，毕竟 pull 不完全等同更新。
再例如提 issue 特指在问题，任务追踪系统中提交一条记录。如果对方并不打算帮你提这个记录，一般说「我报个 bug 」；而说「我提个 bug 」，如果对方是 QA ，可能会帮你提记录，如果是 RD ，对方的意思一定是「我就提一下」，所以这时候会说，「记得帮我提个 issue 啊」来表示特指。

在特指的时候用英文并没有什么问题；但是「 check 」和「我查一下」有什么区别？「 fix 」和「修复」有什么区别？

[crisfun]

@cheka 是，你觉得瞎胡闹也就算了，我也不想和人争论。我说那些更多目的是想看看有没有比较高水平的人来发表意见。

别人抛砖引玉可能还加下说自己诚惶诚恐，我可能懒得说。

[arbipher]

Zipf 定律，涨姿势了

[clearc]

@cuebyte 他们只是觉得用英文的在秀优越感而需要强行扳回一城，我之前这里曾发过咨询帖，里面提到 salesforce 的 workflow ，下面都有人跳出来问我为什么中英文夹杂...只能说没有在国外长期生活或者在外文环境下长期工作的无法理解吧..语言是用来交流的，最直接交流就是想到什么说什么，例如“ defect ”，之前国外的 QC 都是英文，即便和中国人交流也是“这个 defect ”如何如何，后来回国用中文的 QC ，他们习惯用“缺陷”，我反而不适应了挺久..（然而维护母语纯洁性却从没有类似经历的他们，应该不会去用这样二元的思维考虑的...）

[crisfun]

喝口水洗漱回来。

我真正表达的是主客问题。

汉语是主，英语是客，那么就用英语来扩充，能用中文就用中文，这样不论理解还是选词造句速度与准确度都有保证。

但是，偏偏，现在有的人是迫不及待要显示自己那点蹩脚英语。

结果 ，英语是主，汉语是客。这样的时候，不论是理解的速度还是书写的速度，不要说准确性，都反而没了保证。

不信看看楼主自己举的本来想说只要英语好，那么英文妙的例子。这样的蹩脚命名问题，冲突命名问题，他们这些外语人士应该还会遇到的。

[SharkIng]

因为你写代码的时候需要用英文啊。你总不能把 IF 写成 如果（ ruguo i = 1 ）吧？

所以有的时候和国际接轨一些词语没什么奇怪的啊。比如 Bug 。我把这个 Bug 修复一下，你难道非要说我把这个错误修复一下？而且这种简单词汇谁都懂，甚至不会英语的人都知道 bug 是什么..

[miyuki]

读作 “我代码已经提了”，写作 “ git commit ”

个人比较不喜与人交流用 “我去 check 一下”，“我已经 fix 了”

[MrGba2z]

issue 是问题更合适

我同事经常说 there is an issue in this code 。 i'v created a ticket for that 。难道 issue 翻译成工单？工单对应的是 ticket

[linhua]

@arbipher
"Zipf 将此称为最省力原则(Principle of least effort)"
乍一看来感觉好熟悉，原来和“最小作用量原理”差不多。
比较一下
最小作用量原理：（源自刘连寿 《理论物理基础教程》）
一个物理系统实际发生的真实运动状态是所对应的作用量具有最小值的那个状态。

[cxbig]

行业内，这些“黑话”用与不用都没有什么问题。
行业外，中英混杂容易让人无法理解。但硬要扣装 13 的帽子也是不妥。

[myang]

在你的例句里， issue 和 commit 本来就是有所指代的专有名词，用英文替代还算合理；但 check 、 fix 等在这里完全就是普通单词，对应的中文根本不难说，还要故意夹杂的，基本可以肯定是英文水平并不高的人在装 b 。例如如果我是某杂志领导，说了这么一句：“小王啊咱下个月 issue 的 feature 就由你负责了”，这里面几个词在语境中都是普通单词，要这么夹杂就是典型的装 b 。

[Khlieb]

@rwalle 这种话题有可能是些有组织有纪律的人发起的。

[PublicID]

对啊对啊，如果能把 bug 翻译成 feature 就更好了

[lovewilliam]

nope

[fengxiang]

把 app 读 a p p 还真觉得和国际接轨也是醉了。

[sfree2005]

我自己是在全英文的环境下从事编程工作。如果工作外交流的时候发现对方对我我所夹的英文不是很理解的情况下 我很愿意停下来查字典去翻译下。遇到他说的我不懂的中文名词 我也会问， 只是希望对方也有耐心的解释。这样的交流开始的时候是非常低效的，但彼此都在学习，相信很快就会畅通很多。

[Unknwon]

虽然看完评论觉得楼主有软文嫌疑。。但论点非常支持！

顺便吐槽把 issue 翻成 问题 的人， issue 在 github 上是个统带词，不管提问、 bug 、功能请求还是神马，都是 “ file an issue ”，你是说“发起问题”？等你直译久了，我保证你都会觉得自己说中文更 CCTV 的中声发音一样别扭。此处显然是”提交工单“更为合适。

不服来辩！哈哈

[tracyone]

无聊，从小学到大学学了十几年的英语，说几句不行？

[superman]

这个 project 的 schedule 有些问题,尤其是 buffer 不多.另外,cost 也偏高。目前我们没法 confirm 手上的 resource 能完全 take 得了.anyway 我们还是先 pilot 一下,再 follow up 最终的 output,看能不能 run 的比较 smoothly,更重要的是 evaluate 所有的 cost 能不能完全被 cover 掉。

[DennyDai]

一定要把 too young too simple 说成太年轻太简单吗

[hqs123]

还好我身边程序员不是这样的

[guesshehe123]

关键是英文水平不行，有时候真不知道用中文咋说。

[Feiox]

很多著名的或非著名的团队也使用大量中文注释，然后，按照楼主的意思是就会有问题了？

[taine]

“用户报了一个 bug ，我提个 issue 给你”

“好，我 check 下。”

这个绝对没有“好，我看下”省力。

[knktc]

有很多时候其实是因为工具就是英文的，也不知道怎么翻译恰当，就直接用了英文了。比如 git 的一些操作，平时用的 issue track 系统的一些操作啥的。
感觉楼主说的例子都还好，可以接受~

[chinawrj]

呵呵，如果也能"git 提交“的话，我也会说”提交“而不是 commit 。有的时候不是英文单词的事情，而是说这东西已经成了缩写代称，说的时候心里根本不认为这是英文单词。

[skylancer]

issue 是工单？ 不是 ticket 吗？

[feather12315]

@fengxiang 读发音周围人听不懂。。说应用程序吧，估计也不怎么能听懂

[laucie]

LZ 二逼 鉴定完毕

[florije]

……额，好吧，难道是我看的姿势不对，怎么觉得慢慢的软文感觉呢？

[kingme]

论据论点 都没有考虑中国目前所有的软件工程师的英语水平。

你写给前 5%的程序员，这个论点可能是对的。但是针对所有，估计就不对了。

你用英文写注释，是为了给将来团队可能的外国人。那你有没有考虑现在还都是中国的在写代码？成本考虑了么？

[coosir]

@Unknwon 并不觉得翻译成“提交问题”有什么问题。
其实看 file an issue 和 file a ticket 的区别就知道， issue 可以囊括各类的问题，翻译成工单反而狭隘了。

[lijinma]

至少楼主下面的举例中关于“ check in ”这个问题，我是深有体会的。

最后就是：将错就错。

[ldp940622]

@ffffwh 这个"变基"用的好,那天还再吐槽这个翻译

[Cu635]

想 issue 、 commit 这种专业术语最好直接用英文，而且也应该用英文；但是像“检查”“修复”“应用”这些还用英文就不太好了吧……

[blank4me]

你们在这各种争 issue 和 ticket 实际上已经证明了楼主的观点了。
"并非说中文无法表达，而是很多概念在中文有一致的翻译之前就已经得到应用，大家约定俗成的用英文了，这时候用中文翻译反而可能造成沟通不畅。" by @cheka

楼主说的其实还是挺有道理的，完全没看不出来贬低中文，只是说一些场景下英文确实更恰当。比如上面那个 by ，我还真不知道中文要写什么替代这个 by 。

[iugo]

我觉得这个问题是因为: 有些程序上专有专用的英文单词有多种不同的翻译, 为了避免歧义.

[holmesabc]

估计就是软文一篇， 大家何必。

[syyy]

我是来看小恐龙阿贡的。

[terence4444]

这个问题被带偏了，关键是“对谁说”而不是“怎么说”。这么对同事说我觉得完全没有问题，系统里就是这么写的，你非要强行翻译成中文说出来，你的同事还要再翻译回去，有时候一词多义的情况下还会降低效率。
如果对不了解的人说，就适当翻译一下，反正他们也不会去看系统。

说实用和说装逼的工作在不同的环境下，在这个话题上没有共同语言。

[ericshine]

有一句话：不是别人装逼，是你自己傻逼。

[msg7086]

语言主要是用来交流。
顺口说出来的英文不叫装逼。
拗口硬生生夹杂英语或者说得让人听不懂的才叫装逼。

要是说点英语就叫装逼，那我平时找老大闲聊都用日语的叫装啥了。

[bobchengbin]

@all 程序员装个 13 又有什么呢，不会装 13 的程序员能有多好？

[Livisme]

我是来看评论的。。。

[jeremaihloo]

v2 上每每有这种问题都是一番争论，感觉并没有什么意义，怎么开心怎么好

@bobchengbin 我也是这么想的，装 13 应该是人生的乐趣之一

[zyAndroid]

@crisfun 实际上我司的外语水平非常好，但是，母语水平比外语还要好，哈哈哈

[zhicheng]

中文在科技界本来就弱，这和语言没关系。
举个简单的例子，中文的 “安全” 可以同时指英文的 "safe"和"secure" 但这两个词放在计算机科学里，是不同的含义。

所以我是尽量鼓励团队使用英文写文档，注释， UI 等。如果你觉得是在装 B ，那你继续这么觉得好了， I dont care.

[felinx]

Java 、 Python 、 PHP 、 MySQL 、 Redis 、 Github 、 Stackoverflow 、 Quora 、 Google 、 issue 、 defect 、 commit 、 git 、 svn ，程序员不拽英文单词没法工作，程序员不 Google 查英文资料 难获取&学习一手资料，咋进阶呢。贵厂英语水平要求高，我读书是要用贵厂 APP 买四六级保险的人 :) 达不到贵司标准 :(

[XianZaiZhuCe]

需要解释？一个圈子自然懂

[SeanChense]

@superman 你这个反讽压根是两回事。

[felinx]

@kingme 在产品和团队已有一定吸引力的情况下，扇贝他们有条件高标准要求进入的人才。其实我说的有点废话，好像没有前面的条件难道就不用高要求似的。

[mornlight]

哪有那么多时间装 B ，通常只是个人的说话习惯罢了，不要想那么多。沟通的目的是让双方清晰地了解到对方想表达什么，效果到了就行，这事也非要弄个好坏标准有啥意思。

[knightdf]

一是因为大家都会，大家都会的东西能叫装逼吗？ 二是确实是这么表达的，因为你说的这些平常我们也是这么用的，没必要替换成中文

[MC]

这种行为多半不是装逼，更不是英语好。
认识几个单词就是英语好了？中文里夹着几个中文完全能说清楚的英文单词只能说明英文差中文更差，里面很多人单词未必发音能标准，更不要说能流畅说一段话了，更可怕的是，让他们提笔写篇文章，估计很多中文字都写不出。

[cyr1l]

（转）中英文夹杂着说话是习惯还是装逼？
每月把 Portfolio Analysis 发送给全组。这是正常。
每月把资产组合分析 send 给整个 group 。这是装逼。
感受到差别了么

[FrankFang128]

没有时间跟你扯，我在一秒钟前在命令行里敲了 git push ，难度我还要翻译成我刚才 git 推了一下，你 git 拉一下。

这样说话很神经好吗？编程届中英混杂无法避免，谁给我翻一下 Linux 的中文， review 翻译成审查也不对，审查太正经了，而 review 真的就是只是 re-view 一下。

[FrankFang128]

@cyr1l 单词长度低于 5 个字，就是装逼。

[MForever78]

我是前几天才知道句柄原来是 Handle 翻译过来的。

FML...

[liangguan5]

程序员使用 bug 等英文一点都不装 B ，但您的标题「动不动拽英文单词」本身就隐射人家装 B

[kingme]

@felinx 所以如果这篇文章是他们内部论坛的，并没有什么不对。相同的话，放在不同的地方，产生的效果可以是很不同的。

我甚至可以要求我的团队 写 C 不洗 def mian main ，这是我的要求，有什么不可以呢？但是，程序员写 main 就应该写成 mian ！这句话对吗？

[Lonely]

楼主，我 fuck 你

[10iii]

广总：<程序员在工作对话中允许使用的英文单词清单>

[fim8]

真的累。

[learnshare]

编程界仍然是以英语为主要语言的，如果某一天易语言变得大众化，我们也会用中文来装一下。

[g67261831]

有装逼的可能。但不一定是全部。

[leemail]

"总体来说，扇贝对工程师的英文水平要求是很严格的，甚至扇贝程序中所有文字，实际上是先写成英文" ... "打卡被命名为 checkin "

[cyr1l]

再者说了， 装个逼怎么了？ 这世道这么乱， 装个逼都不行？

[StYu]

因为代码是英文（易语言这种异类除外），命令行大多数时候是英文，而且很多工具都是英文的。
说英文更方便对方在界面上找到相应的操作位置，使用对应的命令。
再就是基于以上两点，大家都习惯了。

[029xue]

@leemail 这有问题吗？去酒店第一步不也是 check-in 吗？

[chuhemiao]

只怪我当初英语没学好，你在说啥

[zouxcs]

这个臭虫我已经修改了

[874808862]

会一点的都这样

[Thoxvi]

问题不应该是奔着方便 /高效来的么…习惯就好开心就好为什么要和装 13 扯上关系…

[243205964]

感觉这和装 b 没什么关系吧？习惯怎么说就怎么说啊，大家都能准确的理解就 OK 啊。

[weyou]

@learnshare 这算是有中国特色的爱国主义程序吧