我开始认真琢磨标题里那个fitness适配感是在一次深夜 code review 之后。那天我连续看了四五个小时 Python 代码耳机里放着英语播客等回过神的时候已经把一段if user.is_authenticated and user.has_permission(edit):直接读成了如果用户已登录并且有编辑权限。我没有做任何翻译那个瞬间我突然意识到编程语言和英语之间可能存在一种真实的fitness——不是人为约定而是作用在认知层面的自然适配。这个感觉每个写代码的人多少都经历过只是很少往深了想。为什么编程语言的关键词几乎全是英语为什么英语好的人写代码往往更顺为什么我用中文写注释总觉得哪里别扭这篇文章想聊的正是英语和编程语言之间这种适配从哪里来、有多深、以及我们能拿它做什么。1. fitness不是修辞是编程语言史里的真实筛选机制1.1 英语凭什么站在了牌桌最后先说一个可能让部分人不舒服的事实英语能成为编程语言的底座并不是因为英语比别的语言更适合表达逻辑。从纯逻辑的角度看Lisp 那样的括号表达式、APL 那样的数学符号反倒更接近计算的本质。英语更多是沾了历史的光——现代计算机和早期编程语言大多诞生在英语环境里第一批程序员用英语交流和设计语法是再自然不过的事。但历史的偶然一旦发生就会滚成必然。你写编译器当然用自己最熟的语言设计语法你发布框架注释和文档先写英语你在技术社区提问英语问题得到的回复密度和速度都远超其他语言。于是英语在编程世界里逐渐形成一种基础设施垄断。这里的关键词本身其实少得可怜——if、else、while、for、return、class、function满打满算几十个全是初中词汇。所以背关键词根本不是门槛真正的门槛是用英语组织思维的能力。handleRequest、validateInput、buildResponse这一串函数名放在面前英语语感好的人像读母语一样读过去语感弱的人却要逐个查词、串联、翻译。这中间的认知成本差就是 fitness 最直接的表现。1.2 那些试图摆脱英语的编程语言后来怎样了有人会问既然你说的 fitness 这么重要那造一门全中文编程语言能不能打破它技术上真有人试过。早年的易语言把 Windows API 包装成中文关键词在国内火过一阵前两年还有个叫文言的开源项目用文言文语法重写 JavaScript 语义写出来是吾有一數。曰三。名之曰「甲」这种效果。我第一次看到的时候非常惊艳差点把它当艺术品收藏起来。但冷静下来就知道这种东西可以做艺术表达做教学演示唯独没法撑起一套生产系统——依赖库全是英文的报错信息中英混杂社区里没人帮你排雷CI/CD、代码评审、团队协作全都接不上。这个例子说明编程语言里的 fitness 不是设计得优雅就足够的它更像是达尔文式的自然选择一个语言能不能活看的是它和整个环境的适配度。环境是什么是人是生态是几十年的历史惯性是数不清的文档和开源代码。文言编程语言像一只在沙漠里进化得漂亮极了的生物放到雨林里照样活不下去。英语和编程语言之间的 fitness本质上就是整个技术生态经过几十年沉淀后筛出来的结果。谁与英语适配谁的生态就越繁荣谁就活得久。2. 读代码和高三英语阅读之间的隐秘联系2.1 if、while 与英语条件句坐享同一套心智模型我带过好几个刚入行的新人观察到一个规律那些能快速啃下复杂代码的人当年英语成绩通常不差。这不是因为英语好所以聪明这种粗暴解释而是因为他们早就习惯了处理一种东西——子句嵌套。英语条件句说 If it rains, we will stay at home代码写if (isRaining) { stayAtHome() }英语定语从句说 The file that you uploaded yesterday has been deleted代码里对应的是uploadedFiles.where { it.isDeleted }英语的插入语、介词短语层层堆叠代码里就是一个括号套着三个函数调用。高三英语里折磨过所有人的长难句分析本质上训练的就是人脑解析树形结构的能力。而代码就是一棵被规范化、去掉歧义的语法树这里面确实有英语语法结构带来的顺滑。还有一个容易忽略的点英语大量使用动词介词的短语动词put on、take off、set up、break down。代码 API 的命名几乎完整复刻了这套习惯——setup()、teardown()、login()、breakdown()。自然语言选择这种组合是因为人脑擅长用空间意象去锚定复杂动作编程语言设计者在起 API 名时无意中沿用了同一套策略。老一代前端都熟悉的 jQuery 链式调用$(#app).addClass(active).find(span).text(done)读起来就是一句按时间顺序展开的英语祈使句。说这是文化巧合不如说是认知层面的同构。2.2 变量命名就是名词动词的一篇微作文写代码的人其实每分钟都在写一篇微型英语作文。函数名是动词短语变量名是名词短语参数是限定成分布尔值用系动词或助动词开头。写得好代码是能自己说话的英语说明文写不好就是一堆没有主语的碎片。我 review 代码时最常给的批注其实和逻辑错误无关而是这个名字不清楚。data1tempflaghandleStuff——对应的英语语感是什么是写英语作文时满篇用 thing、stuff、弄一下来糊弄。反过来hasExpiredToken、pendingInvitationCount、resolveUserAvatarUrl你不看实现光读名字就知道这个模块想干什么。这真的需要什么高深的设计原则吗不需要这就是英语作文课上学过的用具体名词、用主动语态、避免指代不明。多数程序员只是没意识到英语的书面表达能力和代码可读性之间的相关性比我们想象中高得多。3. 中文母语者写代码的翻译税我实测出的真实成本3.1 一个简单的阅读速度实验作为中文母语者我一直在观察自己读代码时的翻译机制。几年前我做过一个不太严谨的对比实验找两段逻辑完全一样的代码一段注释是中文一段注释是英文分别计时阅读。结果出乎我意料——看中文注释并没有想象中快多少。我后来想明白了代码本身是英语语法结构大脑刚解析完if (user.isActive)马上要切换成中文去处理如果用户处于活跃状态来回切换是有磨损的。而当注释也用英文写整个过程反而顺滑if (user.isActive)加一句// user can only be modified when active一句话顺着读完零切换。于是我得出一句话总结对我们这些非母语者来说翻译税真实存在。它不在背单词阶段发生而发生在你试图用中文去同化英语代码结构的那一瞬间。中文注释不是毫无用处但在代码这个本就用英语语法搭好的空间里中文注释常常是额外的认知开销而不是助力。也正因为这样我后来写注释、写 commit message、写 issue都慢慢换成了英文。3.2 起变量名时的文化切换为什么好名字都是英文思维起变量名时我能明显感觉到一次文化切换的顿挫。中文思维是用户的名称英文思维要选userName还是username中文思维是是否已登录英文思维要选isLoggedIn还是hasLoggedIn。看起来只是翻译语感却是两回事——isLoggedIn强调的是当前状态系词结构hasLoggedIn强调的是动作的完成时态助动词结构。选错了读代码的人会产生一种微妙的别扭就像听一个老外说我今天很累因为跑步了——意思全懂但就是缺了点什么。拼音命名是另一个大坑。yonghuming、shijianchuo这种变量名写的时候人畜无害等同事接手、等你三个月后回看它就成了一个既不是中文又不是英语的怪胎。国内不少团队的开发规范里明确禁止拼音命名原因就在这。中文命名也不是不行但一旦和英文 API 混搭比如用户名称.trim()语感上的割裂感无处不在。在英语作为通用语的技术环境里英文思维命名是协作成本最低的方式。我现在起名字只问自己一个问题如果把这个变量放进一个英语句子里它充当什么成分这个问题想明白了名字自然就出来了。4. 语言设计者主动向英语献殷勤可读性运动与 API 瘦身4.1 Python 的可读性优先把英语散文作为设计目标如果说历史上英语成为编程语言底座是意外自然选择那从某个时间点开始语言设计者开始主动设计这种 fitness 了。最典型的是 Python。Python 之禅里有一句 Readability counts翻译过来就是代码不只是给机器执行的更是给人读的。人在读什么读的是接近英语的表达。with open(file.txt, r) as f: contents f.read()——这一行读出来正是一句完整的英语祈使句列表推导式[x * 2 for x in items if x 0]也可以理解为一个被高度压缩的英语强调句式。Python 成为公认的最适合新手的语言不是因为它语法多高级而是因为它把英语的自然语序搬进了代码让人能够顺着读下去。对比一下 Perl。当年 Perl 以表达自由著称同一个功能有十种写法结果呢读不懂自己三个月前写的代码成了社区里的经典段子。过度自由会伤害代码与阅读者之间的 fitness。Python 的可读性运动本质上是把英语的自然程度当作一个设计指标在刻意强化而且这套策略确实奏效了。4.2 Swift 重写 API 的启示fitness 可以被主动设计出来另一个好例子是苹果从 Objective-C 迁移到 Swift 时做的 API 重构。Objective-C 老式 API 长这样[tableView insertRowsAtIndexPaths:indexPaths withRowAnimation:UITableViewRowAnimationAutomatic]。它很英语但过于啰嗦像一个把所有从句都展开的长难句。到了 Swift 里同一件事写作tableView.insertRows(at: indexPaths, with: .automatic)。主语动词宾语修饰成分收拢进带标签的参数整个句子的紧凑度和自然度同时上了一个台阶。这个对比告诉我们编程语言和英语之间的 fitness 不是固定不变的常数而是可以被设计者主动调整的变量调整方向高度一致——让代码更接近一个英语母语者自然表达的方式。为什么都往这个方向调因为语言门槛越低生态扩张越快。Swift 用更贴合现代英语语序的 API 降低 iOS 开发的学习成本是一次非常成功的 fitness 工程。顺着这个思路你再看如今的各类现代框架命名越来越口语化、越来越像英语短句都是同一个道理。5. 把语言的fitness变成个人竞争力非母语者的实战建议5.1 坚持用英语写伪代码和注释三周见效的思维切换练习我入行前几年写注释都用中文后来被一位老同事按着头改成英文。过程痛苦但现在回头看那是我做过性价比最高的一次习惯改造。做法非常简单从明天开始所有伪代码、代码注释、TODO、PR 描述、commit message一律用英语简单句写不用纠结语法先把意图表达清楚。比如你脑子里想的是把这个用户的数据存到数据库再刷新列表写出伪代码就是saveUserData()、refreshList()。一开始你必然会先想中文再翻译成英文坚持两三周后你会发现自己开始直接生成英文结构看到updateProfile时第一反应是更新资料这个动作本身而不是update 是更新profile 是资料。跨过这一步读文档、读源码、搜英文报错都会有质的飞跃。5.2 错误信息、搜索关键词和英语语感很多新手遇到英文报错就慌第一反应是找中文翻译。我的建议是千万别。技术术语翻译成中文后经常失真undefined is not a function翻成未定义的不是一个函数你反而更懵。正确做法是把报错信息当成英语句子来拆Cannot read property length of null主语省略的祈使式谓语 cant read宾语 propertyof null 是定语。语法一拆完问题根因基本就清楚了而且拆多了你会发现报错信息的语法结构其实非常固定品类就那么多。搜索也是一样。我现在几乎不用纯中文搜技术问题不是矫情是踩过太多次坑。搜Python 列表推导式 双重循环 顺序和搜 Python list comprehension double loop order后者的信息密度高一个量级。英文技术问答社区里把边界条件和踩坑经验讲清楚的帖子绝大多数情况下比中文搬运文靠谱。现在用 AI 辅助写代码也同理我拿英语描述需求时得到的代码质量明显高于中文描述因为模型训练语料里英语代码的占比本身就高。这个习惯的本质就是用英语语法去匹配英语世界的信息结构等于让互联网上最好的技术内容变成你的外挂。5.3 从源码里偷学技术英语句型读源码通常是在学算法和设计模式但源码注释和 commit message 里还藏着一座常被人忽略的金矿技术英语的高频句型。我随手整理过几个最常见的句型用途常见位置Ensure that...描述前置条件、防御性检查方法注释、throws 附近Note that...提醒边界情况和注意事项方法注释末段This method is called when...说明触发时机回调方法注释Return true if..., false otherwise描述布尔返回值语义谓词类方法Throws an exception if...描述异常条件异常处理相关文档commit message 也遵循一套固定语法动词原形开头加名词短语Add user profile page、Fix session timeout bug、Refactor auth middleware。这就是英语祈使句的标准用法。我以前带过一个英语四级压线的实习生坚持用这个方法啃了三个月开源项目的 commit 和注释后来写出的 PR 描述比我见过的大多数工作五年的人都地道。技术英语不需要背单词书它是一套有套路、有模板、可积累的职业方言最好的老师就是平时读的每份源码。写到这里我又想起那个深夜。所谓fitness说到底就是你读代码时不再需要翻译的那个瞬间——英语、代码、逻辑三者连成一条线大脑毫无卡顿地顺着线滑过去。它不是靠背出来的是靠一遍遍在真实的代码里浸泡、把英语当成代码的一部分去习惯慢慢长出来的。中文母语者要比母语者多付出一点刻意练习但一旦跨过那条翻译的边界线你会发现英语不是学来的而是你写代码时顺手养成的本能。