看到庄表伟的《开源社区应该选择什么语言？》一文，其中建议一刀切地使用英文命名标识符： 我们将一个源代码文件，看做一篇完整的文章。在这篇文章中：中英文夹杂，甚至英文加汉语拼音混杂都。..

                                                                                                                                                                                    看到庄表伟的《开源社区应该选择什么语言？》一文，其中建议一刀切地使用英文命名标识符：

不得不来发表些个人观点。在《Gitee 开源指北》第 5 小节：有关开源的常见误区 中，有与本文同题的一节进行阐述。三个月前还围绕此部分进行了一场 持续数日、来回数十回合的论辩。有兴趣的可以细看，此文仅分享一个两年半前的开源合作实践经历。
那天在 v2ex 碰到一个开发请求，由此催生了 五笔编码编辑器 这个微型开源项目，此为 事后结贴。
Test
九月十八日开始合作时，请求者 明说无编程经验。在原型搭建时，我提到会使用中文命名，最后实现的 Python 代码片段如下：
一开始很希望之后的维护由他多出力，但感觉那时他的动力并不大。花个把礼拜做出了雏形，意外和惊喜的是，这位在九月二十八日就提交了这个“照猫画虎” PR，并且之后持续改进，十月之后我除了合并 PR 之外基本没有投入其他精力。
可见中文命名对于鼓励新手参与开源项目的作用。
开源项目的基本架构搭建之后，如果项目本身使用的是中文命名，用户（往往非程序员）应该会更有动力去学习代码。并不是说英文命名肯定会阻止参与项目，但会让很大一部分人望而却步。
实际上开源项目很大一部分工作量在于后期维护、界面改进、相似功能的堆积，以及相关测试。这部分完全可以由原作者之外的参与者，即普通用户来实现，原作者就可以专心投入到架构/大功能的优化改进上。久而久之，编程新手也会逐渐成为熟练程序员、核心贡献者。
能够吸引更多人来投入项目，而不是点个星就走，是开源项目能够壮大和持久的关键。任何能够降低参与门槛的技术，都应该值得项目作者认真考察，根据项目酌情决定。
回忆一下，无论是开源还是闭源项目，过去几周有没有碰到如下情况之一：

翻自己之前写的代码，发现某个标识符不知所谓
看别人的代码，不懂某个标识符
同事来问你某个标识符啥意思

在我看来，这种时候就可以考虑一下，将这个标识符改成中文会不会少些麻烦。大可以从需要的地方开始改，不用上来就把整个项目的标识符全部中文化。
补：最常见的问题之一是：”用中文命名之后，国外开发者如何参与”? 对此在《Gitee 开源指北》中也有提及，可以另开文章详述。

中文命名的实践价值

一、降低参与门槛

使用中文命名标识符最直接的好处是降低了非英语母语开发者的参与门槛。对于中国的开发者来说，使用母语命名可以：

  1. 提高理解速度：不需要在脑海中翻译，直接理解代码含义
  2. 减少命名错误：避免因英语水平导致的命名不当
  3. 增强代码可读性：对中文用户来说，中文命名更直观

二、实际案例：五笔编码编辑器

在五笔编码编辑器项目中，使用中文命名取得了显著效果：

  • 新手友好：无编程经验的合作者能够快速理解代码
  • 快速上手：合作者在短时间内就能提交PR
  • 持续贡献：降低了维护成本，项目得以持续发展

这个案例充分说明了中文命名在降低参与门槛方面的价值。

三、命名的最佳实践

1. 渐进式改进

不需要一开始就把整个项目全部中文化，可以：

  • 从新代码开始：新写的代码使用中文命名
  • 重构时改进：在重构时逐步改进命名
  • 关键部分优先：优先改进核心业务逻辑的命名

2. 保持一致性

无论使用什么语言命名，都要保持一致性：

  • 统一风格：整个项目使用统一的命名风格
  • 避免混合：避免中英文混合命名
  • 专业术语：技术术语可以保持英文，提高专业性

3. 考虑可维护性

命名不仅要考虑当前的可读性，还要考虑：

  • 长期维护：考虑项目长期维护的需要
  • 团队协作：考虑团队成员的背景和能力
  • 工具支持：确保开发工具对命名有良好支持

四、关于国际化的思考

4.1 国外开发者参与的问题

这是使用中文命名时最常被问到的问题。实际上：

  1. 文档国际化：可以通过完善的英文文档来弥补
  2. API设计：可以提供英文API，内部实现使用中文
  3. 渐进式国际化：先服务好国内用户，再考虑国际化

4.2 多语言支持策略

一些项目采用了多语言支持的策略：

  • 双API设计：同时提供中英文API
  • 命名空间分离：不同语言使用不同的命名空间
  • 代码生成：通过工具生成多语言版本的API

五、技术实现考虑

5.1 编程语言支持

现代编程语言对Unicode标识符的支持：

  • Python 3：完全支持Unicode标识符
  • JavaScript/TypeScript：支持Unicode标识符
  • Java：Java 9+支持Unicode标识符
  • C#：支持Unicode标识符
  • Go：不支持Unicode标识符（这是Go的一个限制）

5.2 工具链支持

  • IDE支持：主流IDE对Unicode标识符的支持已经比较完善
  • 代码分析工具：需要确保工具链支持Unicode
  • 版本控制：Git等工具对Unicode的支持没有问题

六、社区观点和讨论

6.1 支持中文命名的观点

  1. 降低门槛：让更多开发者能够参与开源项目
  2. 提高效率：减少理解代码的时间，提高开发效率
  3. 文化多样性：体现技术社区的文化包容性

6.2 反对中文命名的观点

  1. 国际化障碍：可能影响项目的国际化推广
  2. 工具支持：某些工具对中文支持不够完善
  3. 行业惯例：大多数开源项目使用英文命名

七、实际建议

7.1 适合使用中文命名的场景

  1. 主要面向国内用户的项目
  2. 教育类项目：教学用途的项目
  3. 内部工具：公司内部使用的工具
  4. 特定领域项目：涉及中文处理的特定领域

7.2 不适合使用中文命名的场景

  1. 国际化项目：面向全球用户的项目
  2. 底层库：被广泛使用的底层库
  3. 标准实现：实现行业标准的项目

八、总结

标识符命名是一个需要综合考虑的问题。中文命名有其优势，特别是在降低参与门槛、提高代码可读性方面。但也要考虑项目的国际化需求、工具支持等因素。

最重要的是，不要盲目跟风，要根据项目的实际情况做出最适合的选择。无论是中文还是英文，清晰、一致、易维护才是最重要的原则。

本文标题： 开源项目必须用英

发布时间： 2019年04月14日 00:00

最后更新： 2025年12月30日 08:54

原始链接： https://haoxiang.eu.org/fcec288c/

版权声明： 本文著作权归作者所有，均采用CC BY-NC-SA 4.0许可协议，转载请注明出处！

赏
× 喜欢就赞赏一下呗！
打赏二维码