所有开发者母语都是中文时, 为什么大多数项目仍然选择英文命名?

[nobodxbodon]

除去客户要求代码必须是英文的项目(比如外包项目). 应该有很多因素, 这里尝试搜集那些"硬"的理由. 请补充.

• 已有的代码风格和格式规范的文档都是基于英文命名而制定的 @hummerstudio 所有开发者母语都是中文时, 为什么大多数项目仍然选择英文命名? #18 (comment)
• 从别处粘贴复制代码简单
• 不同操作系统的默认编码方式不同, 比如代码库在Linux机器, 开发机是Windows, 容易出乱码问题
• 依赖的库或者工具对unicode支持不佳(比如这里22楼发现的Spring的Thymeleaf不支持中文变量名)

[swizl]

只是因为英语目前是强势语言。在各个领域资源都是最丰富的。而且写出来的代码，需要被人认可，才有价值，用英文更加容易被认可。当中文成为强势语言时，大家也会倾向中文，拉丁文、法语同理。中文编程目前做能做个人的爱好而已，但是爱好中文的人和公司多了，中文才能强势起来。那些现在不愿意用中文编程的人才可能正视中文编程。

[nobodxbodon]

@swizl 你说的确实是现状. 那么为什么英文代码更被人认可, 感觉应该有历史和现实的一些技术原因. 即使英语是强势语言, 绝大多数中文母语的程序员之间交流技术问题还是用中文吧.
除了顶楼列的一些问题, 一些语言本身非常早期不支持unicode命名, 比如JavaScript, 根据这里, 1998年间之后才支持.

[azige]

其实关于这个问题，本人觉得隔壁 #3 (comment) 引用的问题 Should you use international identifiers in Java/C#? 就解释了 历史和现实的一些技术原因 ：ASCII字符集包含了所有英文字符。

[ice1000]

输入方便啊。比如我最近的项目，输入只需要按三下 -> https://github.com/Cm-lang/Cmc

[nobodxbodon]

@htwx 开这个主题帖的目的也是为了探究为何没有国内公司的开源项目用中文命名. 现在感觉, 除了惯性使然, 估计技术上还是为了规避各种编码问题和第三方库对unicode支持的问题(都在顶楼).

[hummerstudio]

1. 各种介绍代码风格和格式规范的文档。 这一点原因一定要重视，而且我认为是主因。对自我有高要求的开发者，学习编程到一定阶段，都会去看这一类的文档。由于这些文档大部分是国外的大公司（谷歌、微软等）编写的，因此不可能提出使用中文来命名变量名、函数/方法名的说法，一般都是根据英文的特点，使用匈牙利命名法、骆驼命名法、帕斯卡命名法等等。国内大公司制定自己的规范，当然也是依据这些再结合公司情况来的。这些命名法一般是通过字母大小写、缩写字母前缀、常用单词简写等方法来增强代码可读性。这些观念先入为主后，再使用中文命名就会有些无所适从、用不上了。事实上这也是使用中文的优点，因为英文单词是不定长的，放在一起相区分就得用大小写或者连接符来分割，比如用户名，使用英文就可能是userName，UserName，user-name，user_name等等（user还有可能简写为usr，这样情况就更多了），使用中文变量就非常简单了，就是”用户名“。
2. 由1导致的对权威的盲从。 因为代码规范成了一门学问，不去学习而转而使用中文，自然就成为一个负面的概念了，有点逃避，不求上进的意思。
3. 一些语言、工具对中文的支持不佳。 这也是现实情况，因为使用中文的少，所以肯定有不完善的地方，比如编码问题，乱码，或者打印出来是\xxxxx形式的Unicode码，而不能直接显示汉字等。这个地方是中文编程支持者可以努力的地方。因为这些问题的存在，一些人可能尝试过使用中文，但是发现不支持、支持不佳或需要耗时解决、找不到相关解决办法时，就会偏向于不去触碰这个坑，转而去老老实实使用英文。
4. 由上述原因导致的自卑感。 不从自己的角度出发解决问题，而是抱怨国人不能解决这些问题，不能开发自己的语言，认为计算机是英文的天下，英文是通行语言。从而产生自卑心理，自我否定，失去改变现状的想法，并去鄙视那些试图改变现状的人。当然这个是正常的，它和近代民族自卑心理的产生和对汉字的否定如出一辙，我们没有必要去批判什么。这些都是人的正常心理。对于此，我们也只有少空谈，多实干，真正做出实践和改变，才能改变大家的看法。

以上是我早些年对此问题的思考，我认为也是比较客观的。目前中文编程未成体系（易语言和习语言其实是很不错的，很遗憾的是并不开源，但很多方面还是可以学习借鉴的），在没有成绩的情况下，不能指望说服大多数人。

[nobodxbodon]

各种介绍代码风格和格式规范的文档。 这一点原因一定要重视，而且我认为是主因。

同意. 已添加到顶楼. 之前写Java上手教程的时候, 在最后零 没有规矩, 不成方圆 - 代码风格也试图添加了一些和中文命名相关的内容(第4部分-命名). 请多补充.

一些语言、工具对中文的支持不佳

同感. 最近碰到的UTF8<->GBK互转出现部分乱码的问题就是个实例. 我现在是倾向碰到一个坑就尽量研究透, 即使不能解决(第三方库作者不一定配合), 也至少明白原理, 然后最好有规避的办法.

对于此，我们也只有少空谈，多实干，真正做出实践和改变，才能改变大家的看法。

+1

[nobodxbodon]

在知乎回复中对顶楼的几条的再思考. 其中与@hummerstudio 楼上的总结有共通之处:

第一条实际上是恶性循环的后果(只有英文命名的代码->没有中文命名的风格->难以开展中文命名实践->更总结不出风格). 第二条也类似, 但相信也有迫于压力不愿分享中文命名的代码的因素. 而后两条是比较"硬"的技术原因. 第三条其实是容易解决的, 只要把源码文件都统一编码并成为一个团队内部的共识即可, 即便如此也足够让很多团队望而却步了. 第四条是真正的直接影响在代码中使用中文的决定性因素. 一旦项目选择的框架有此类问题, 那么即使这个框架是开源的, 也几乎不大可能花时间去为了使用中文命名而改进框架. 而这个问题也其实间接是由中文命名的实践少而导致的. 如果自己(母语是中文的开发者)都不在这些开源框架的社区中发声的话, 国外开发者更不可能为这个需求(在框架中使用中文命名)花费额外的精力.

个人感觉, 实践中文编程(即使只是用中文命名而已)在实用项目里的阻力, 不外乎一条 - 避险. 而这是非常非常合理的. 如果没有先前的亲身经验积累(确认所有外部依赖的框架/库中全面支持中文命名), 相信不会有一个产品负责人会在内外压力下决定吃螃蟹采用中文命名. 而在几乎所有公开分享的源码都是英文命名的情况下, 仅靠自己来积累这个经验教训是几乎不可能完成的任务, 即使有公司总结出了一套适合自己团队的中文命名方式, 也很可能是只适用于他们项目使用的框架/环境. 而愿意公开分享这些经验教训的毕竟是少数. 这样又反过来使得这类实践更难以推广.

那么, 为了逐步解决这个死循环, 不才建立了中文编程专栏, 一部分关注就是在现有的语言/框架中使用中文命名. 希望通过一些深浅不一的尝试, 逐渐探究出一些可行的对中文命名足够友好的开发套路, 也为有志于此类实践的同好提供一个交流分享的场所. 欢迎希望用中文写代码的各位群策群力, 以分享促加速推广.

如果没有额外补充, 个人感觉这个帖子已经达到了目的. 可以总结之后(发在知乎专栏和讨论组对外网站)结帖了. 欢迎发表不同意见建议.

[nobodxbodon]

已发文中文命名实践的阻力和应对.
如有补充请重开此贴.