多语言编程的设想：将变量名与自然语言解耦

[Andy-AO]

前排提醒，怕来低级黑

1. 中文编程主要是用于变量名，在义务教育普及的年代，没人想改关键字。
2. 中文编程普及的前提是编译器支持 UniCode，已经实现。但还有很多问题尚待解决，下文说的是重要问题之一。
3. 中文在某些情况下可能优于英文，并不是要在任何场景下使用。

重要问题

用更熟练的语言思考，对于提高思考的质量和速度都有很好的帮助[1]。

由于中文在编程界不是通用的语言，所以用它编程的重要问题是 —— 没有办法和其他国家的人进行交流，老外一看变量名都是方块字，估计直接劝退了。

软件界面多语言已经很常见了，代码也可以有这个思路。

让自然语言和编程语言在写变量名方面解耦，可以先用母语写变量名，并用来思考编程问题，发布的时候，然后再逐渐翻译，就像现在的软件那样。

变量名与自然语言解耦的好处

1. 提升命名质量：
   • 专心思考：由于代码和自然语言解耦，可以用专门时间来思考变量名问题，而不是在思考编程问题，手忙脚乱的时候，同时考虑命名和翻译两大问题。
   • 后期修改：后期修改非常方便，当有灵感的时候修改 XML 文件就行，不用打开 IDE 重构。
   • 全球协作：由任何人提出 PR 随时修改英文变量名，总有人能比你想到更好的，比如英文更好，或者就是刚好有灵感。
2. 提升编程体验：英文不熟练人，能很好的腾出工作记忆，在编程的时候，更好的专注于编程本身。
3. 隐秘使用：如果周围的环境对中文变量名不够友好，可以自己用中文提交代码的时候用英文。
4. 全球化支持：同一段代码不仅有中英双语，其他国家的人只要是有这个意思，也可以快速的进行翻译。GUI 软件常常会支持好几十个国家的语言，那么代码也可以。

可能的实现途径

JetBrains 系的 IDE，都有重构的功能，调用重构功能换变量名，应该就能实现。

代码混淆器，好像会替换变量名而让软件功能保持不变，如果有开源的，应该可以利用。

注释 1

...

一个是 Leontiev 通过研究发现，在进行外语交流时，有一个把母语思想用外语形式表达之前的一个“过渡阶段”，在这个时候才用外语思维。其他时间一般都用母语思维。这也就是说，交流前的深度思维，或者“筹划阶段”，一般都是用母语思维的。但 Leontiev 研究的对象大部分都是使用“翻译法”学外语的。那么他研究的这种存在“过渡阶段”思维的对象，是否是因为用“翻译法”学外语造成的呢？这一问题成为了 Loentiev 研究结论的致命伤。

另一个是 John-Steiner 提出的阶段性和统一性的理论：外语初学者习惯用母语思维来帮助理解外语，当达到中级阶段时，就会尽量避免依赖翻译而直接使用外语思维来理解外语，但真正到了高级阶段，大脑中的母语和外语形成的高度联系统一的“语义”系统，双语者可以很自由随意地使用两种语言代码。

研究表明，有经验的翻译人员在翻译工作中，已经做到了可以表达超出单词表面意思的直译，达到深度含义的意译的翻译水平，指的就是这个高级阶段。许多对双语流利的人的研究也都显示：在思考问题时，经常会没有意识到自己刚才到底在用哪种语言思维或可能两种都使用了。

...

《找对英语学习方法的第一本书》

如果大多数英语不好的人都会用母语思维，然后再用翻译形成英语，那么根据工作记忆有限的事实，直接用母语思考，有可能会减轻负担，从而提高思考的质量。

还有就是，这里说的用母语思考效率可能更高，指的是英语比母语熟练度明显差的，大多数人可能都会这样，因为毕竟在国内的环境中，练习的机会少很多。

如果英语和母语已经差不多熟，那么不需要。

---

简单的查了一下，Multilingual variable name，和“多语言变量名”，好像没有发现类似的项目，所以将这个灵感发出来，如果有精通写 IDE 插件，这方面的人，也许会有点兴趣吧。

[nobodxbodon]

你好。之前看到过一些类似建议，不过在讨论具体实施细节之前，不妨先对需求进行一下分析吧。

相信我们的共识是中文（母语）命名在开发时具有一定优势，因而开发者会选择在项目伊始就使用中文命名标识符。如果是这样，那么至少在该开发者可预见的时期内，该项目的设计者、合作者应该都会中文，更关键的是，各种文档和项目相关术语应该都是中文的。如果本来就是在以外语作为日常交流语言的开发组内，使用中文命名的动力应该相当低，因为文档和术语等等都会是外语。这两种项目应该都不需要代码国际化。

在国内闭源项目中，绝大部分应该属于前者（项目参与者的母语都是中文）。极少数头部公司会有属于后者的项目，但比例应该也不大。

再说开源项目，之前有过一些思考，简单来说，如果真的有面向国外用户的打算，那么首先用户手册就要有外文版的，并且界面文字国际化。如果是面向开发者的 API 相关项目，API 也至少会有中外两种版本。

假如项目真的到了国外开发者有意参与贡献、维护代码的阶段（在国内开源项目中应该是极少数），那么需求、设计等等文档尤其是术语表首先需要国际化，再接下去才轮到内部实现代码的国际化。

请不吝赐教。

[Andy-AO]

之所以目前中文编程的人少，就是因为转移的过程太痛了，问题太大了，而不是说中文编程没有用，实际上有用的很。这个项目的目的在于让更多的人，能无痛的，安心的转向使用中文编程，解决转向过程中的痛点。

你说的共识是不存在的，我们考虑的场景是不一样的，大多数的公司不会在项目开始就用中文，这对转向造成了很大阻碍。

下面我扮演在网上看了关于中文编程的介绍，决定从今天开始只使用中文编程的程序员。以后我的代码都是中文的了。

但是由于中文编程目前不流行，所以会受到很多障碍，但有了这个项目之后，就可以在开源和闭源两种情况之下，都方便的使用中文，下面是具体案例：

1. 闭源公司项目：如果在公司里环境允许用中文，那么很好，现在就可以用了；如果公司不让用，那我可就遇到麻烦了，因为同事们是不会接受中文代码的。有了这个项目就解决了！自己用中文写，在任何时候都可以改成英文的变量名，然后再提交。 可能是零碎时间，也可能是很大的空闲，这个无所谓，因为已经解耦了，可以随时随地改。 在这个情景之下，根本就没有“不用国际化”的问题，本来就不用国际化，只是用中文编程的我，作为另类，我必须照顾同事，和“国际化”没有任何关系。 之所以有这个疑问，纯粹是还用老思想考虑问题，由于项目自从开始就用英文，所以没有办法用中文编程，中文编程只能在立项之初就用中文的项目中使用。可这就是本项目所解决的问题啊！

2. 开源项目：我想用中文编程，但也想让外国人了解开源项目，以扩大此项目的影响力。用中文编程后，首先应该写英文的README等内容，让外国人检索到，然后就是写文档，但这些部分的确已经解耦了，所以这个问题本身就解决了，根本就不存在障碍，如果这些东西都没有翻译，那根本就没有考虑国际化！关键是变量名的问题，设想如果变量名都是中文，即使有英文文档，外国人也不会用的吧，除非你的东西完全不可替代。因为他们在IDE中无法用之前的方法调用代码，既不懂汉语也不懂拼音，只能用复制粘贴的方式调用方法和访问属性，谁会喜欢这种方式呢？ 真正的问题是我写的代码别人看不懂，而且我也不好翻译，因为翻译起来太麻烦，那么我做出这个决定之后，外国人看见代码里都是方块字就跑了，就意味着和国际彻底脱轨了。但有了这个项目之后，项目就能真正的和国际接轨，让外国人也能够看懂我写的代码了！ 当然，如果在内部项目中也有国际化的意思，让各个国家的同事用自己的语言编程，那么这个场景也是可以出现的。

这就是对你提出的两个问题的回复，如果我没有能理解好你的问题，请留言告诉我。

[Andy-AO]

至于你说的之前的想法，我觉得确实有一些类似的地方，但那个想法的难度太大了。大概看了，貌似是涉及到编程语言和编译器的层面吧，如果我没理解错的话，用主席的话来说就是“蚂蚁缘槐夸大国，蚍蜉撼树谈何易”，就这么点人，还想到编程语言和编译器层面上去了，简直是痴人说梦，看不到任何希望。

这个思路是在现有的体系上增加内容，如果已决定使用中文编程，那么立即就可以用，当需要国际化的时候往里面增加文本文件就行，由于是高度解耦的，不对现有的工作造成任何的影响，也不用管编程语言和编译器层面的问题。

而且这个国际化还是可以随时随地分阶段进行的，什么时候想起来要做了就可以做。

这个项目的初衷是让人能够安心的转向中文编程，这就好像走钢丝的新手都要用带安全绳是一样的，有了安全绳，所有人都可以加入到这场冒险当中！

走钢丝的新手因为有安全绳的保护，不会出现真正的危险，所以，他们愿意尝试；同样的，转向中文编程的人，因为有了这个项目感到很安心，编程后，可以利用闲暇时间进行翻译，等到必须使用英文变量名的时候，可以直接转换为英文，完全的无缝衔接的。

安全感很重要，否则少有人会愿意冒险。

[tuchg]

个人以为，想法上是不错的一个创新 先不论国际化问题，就谈国内圈子和团队合作，大部分从业者（顽固偏执且盲目地认定英语才是标准）不太能用英语翻译的业务非要用英语命名，这种不破坏源码的方式能很好解决这类分歧

[Andy-AO]

个人以为，想法上是不错的一个创新 先不论国际化问题，就谈国内圈子和团队合作，一部分人不太能用英语翻译的业务非要用英语命名，这种不破坏源码的方式能很好解决这类分歧

赞同，你理解了这个项目在可行性方面的巨大优势。

[nobodxbodon]

@Andy-AO

多谢阐释。只要可能促进中文命名推广的方法，就值得好好研究。

自己用中文写，在任何时候都可以改成英文的变量名，然后再提交。

这个需求的确听到过，也看到过将中英代码互转的工具。应该还可分为两种场景：

1. 开发依赖的库或者框架暂不支持中文命名（应该会越来越少）
2. （如你所言）团队用英文，个人用中文

因为他们在IDE中无法用之前的方法调用代码，既不懂汉语也不懂拼音，只能用复制粘贴的方式调用方法和访问属性

如果国外开发者只需使用 API，那么英文版的 API 和文档应该够用。如果针对乐意参与贡献代码（改进、维护项目）的国外开发者，那么这个需求也成立（场景3）

下面就基于这三种场景来探讨吧。

场景 1，由于英文并不需要直接让人看，那么对英文命名的可读性可以没有要求，只需保证代码转换后的正确性即可。这对翻译的要求最低。

场景 2，这种情况下，往往是一直有较大量英文代码需要中文化。或者从流程角度说，相对而言，更多时候是中文跟着英文走。

场景 3，应该是中文代码是基本，相对而言是英文从中文。但同时对英文可读性要求最高。

三种场景下都需考虑的（欢迎补充）：

• 代码正确性

  虽然 IDE 都有重构功能，但就个人体验，大量、多次重命名往往需要人工辅助。如果是全自动，不确定会有多准确（需要多少额外纠错）。

• 翻译质量

  之前尝试过对标识符进行英->中的在线翻译、本地词典机翻和手工翻译（VueJS、方舟）。虽然没做中->英的实验，但前两者恐怕都很难达到场景 3 的要求。为了保证翻译质量，一个中英术语表应该是必需的，像是这种游戏开发中的中英文对照表。

• 代码保存、版本控制

  中英两个代码版本是否都进行版本控制？在场景 1 中，也许英文代码不用保存。如果都保存，就需保持同步。

• 调试

  如果运行时用的是英文代码，那么比如报错信息或者调试中的标识符也需要相应中文化。

当然，说千道万不如动手一试。

在一个相对小型的项目中进行一次实践相信会有更直接的体会。个人认为 @tuchg 的中文代码补全插件正好是英文命名，就是个很好的场景 2 的实例。比方说 @Andy-AO 可作为一个新参与者，尝试用中文命名部分代码并与英文代码同步，共同完成一个新功能（也许就这个中英互转功能？）。

个人时间精力有限，但乐于协助测试、文档等等。

[Andy-AO]

The Sixth Epoch
和我的想法基本相同。在那个issue里我也有发言。

多语言机制的一个非常大的好处就是彻底解决了术语定义问题（世界上编程语言层出不穷的原因之一就是每个人用语用词习惯的差异性），无需为一套统一天下的术语体系绞尽脑汁而实际上不可能有最终方案。

@The Sixth Epoch
不太清楚编程语言层出不穷的原因，我的那个想法是自然语言与命名解耦和编程语言没有任何关系。

[liuxilu]

rand name 回复在“为什么都说易语言不好？易语言不好在哪里？ - pansz的回答”说：

那个IDE可不是简单的“汉字编程”，这么说是因为你没试用过已被抛弃的英/日/俄文版易语言。理论上易语言代码可以用任何其他语言书写和显示。 使用英/日/俄文版易语言打开中文版易语言代码文件，全部关键字自动转译为对应语言，而且可以正常编译（前提是没有使用到对于这些已被弃用版本来说过新的特性）。

[nobodxbodon]

@liuxilu 多谢分享。看了一下这位的意思应该是易语言可以把关键词自动在多种语言之间互转，而不是标识符吧？

[liuxilu]

呃，看错了

[s20208413]

是个好想法, 通过工具应该可以实现

[zzp198-old]

额，这不和代码”混淆“差不多吗，自己用喜欢的语言写完后，能把变量名“混淆”成各国的语言，别人更改后，也能输出不同变量名但意义相同的代码。

我倒有个想法，可以维护一个全局的变量表，代码中记录id，值为各种语言翻译后的变量名，代码文件保存id，在ide中显示id翻译后的值。不同的变量名，但如果指的都是同一个id那么就算为同一个变量。 不过现在的ide没这么智能，变量的作用区域也很容易出错。

将变量名与自然语言解耦 ×
将中文推广到全世界 √