虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。2007 年 Python3 决定支持非 ASCII 码标识符的增强建议书中指出：

A developer wishing to make a library widely available needs to make a number of explicit choices (such as publication, licensing, language of documentation, and language of identifiers). It should always be the choice of the author to make these decisions - not the choice of the language designers.

这段话同样适用于开源项目。无论是文档还是源码中标识符使用的语言，项目作者都可以根据实际需求来灵活决定，而非简单的一刀切用英文。实际上，开源项目往往是在开发者业余的碎片时间进行，文档和测试往往从简。这种情况下，代码的清晰度和可维护性对于项目可持续性尤显重要，这恰恰是母语命名标识符的优势。正如同一文档指出：

By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.

下面是一些常见的顾虑：

  • 用中文命名出了问题怎么办？

    像任何技术一样，在使用推广中必然有各种问题出现。如果是编程语言或是开源框架对中文命名的支持问题，可以向它们的开发组反映，往往能得到解决，先例有 Vue.js、Hibernate、pip 等等。另外，也可在开源中国社区求助、协力解决。毕竟，「走的人多了，也便成了路」。

  • 框架限制必须用英文怎么办？

    比如 JavaBeans 规范一定要使用 set/get 前缀。即便如此，仍然可以使用中英混合的命名，只要开发者感觉更易读即可，比如 getCostOutcomeRatioByClientGroup 相比 get投入产出比By客户组。类似地，一些常用的英文术语或简写，如果没想到合适中文对应术语，大可以暂时保留这部分英文命名。

  • 中英文混输的效率会低吗？

    大多数情况下，读代码的时间远超过写代码的时间。即便仅仅讨论写代码的效率，也要考虑推敲英文命名甚至查字典的时间，何况很多领域业务相关命名连恰当英文表达都很难找到。另外，随着中文命名实践的普及，相应的 IDE 辅助功能也在不断涌现，比如 JetBrains 和 VS Code 的中文代码补全插件。

  • 项目已经是英文命名的，没法转了？

    如果某一部分的英文命名经常在开发组中引起误解或者新手甚至自己也难以看懂，可以尝试从这部分先开始中文化，看看效果后再逐步在其他部分采用。与任何未曾尝试过的技术一样，渐进增量式的应用可以减小风险、在使用中逐渐适应。

  • 用了中文命名之后，怎样为国外用户服务？

    如果需要面向国外用户，首先要对用户界面和使用文档进行国际化。如果是库，用户界面就是 API。技术上，可以开发中英两套 API。如果想更进一步，鼓励国外开发者参与开发项目，当然可以逐步将命名英文化，但也应综合考虑是否值得。

总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。

非英文母语命名这一技术虽早已面世，但在中文开源社区中的实例仍然寥寥，原因是多方面的。随着

可以用Rust 设计者

2007 年

本文针对开源中国这一平台所作

不。

可读性

面向何种用户

  • 开源中国这一平台的特殊性。

标识符 API 界面

甚至有不会英文，改用拼音甚至拼音简写的情况。

开源特性

  • 碎片时间
  • 强调个人作用
  • 可读性审核缺乏
  • 用户需要更小门槛，鼓励参与

参考：