2017-11-14 中文命名实践的阻力和应对

原址: https://zhuanlan.zhihu.com/p/31069294

中文命名在商业项目中至今没有大规模应用. 此文试图对它的原因做些粗浅探究.

讨论组中的帖子所有开发者母语都是中文时, 为什么大多数项目仍然选择英文命名? · Issue #18 · program-in-chinese/overview里初步归结出几个问题:

• 已有的代码风格和格式规范的文档都是基于英文命名而制定的
• 从别处粘贴复制代码简单(因为绝大多数找得到的代码都是英文的)
• 不同操作系统的默认编码方式不同, 比如代码库在Linux机器, 开发机是Windows, 容易出乱码问题
• 依赖的库或者工具对中文支持不佳(比如这里22楼发现的Spring的Thymeleaf不支持中文变量名), 最近的发现有Angluar对中文支持有限(中文代码示例之Angular入门教程尝试)

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

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

中文编程专栏的一部分关注就是在现有的语言/框架/工具集中使用中文命名. 希望通过一些深浅不一的尝试, 逐渐探究出一些可行的对中文命名足够友好的开发套路, 也为有志于此类实践的同好提供一个交流分享中文代码的场所. 在此过程中, 逐渐积累中文代码的数量, 并对中文代码风格进行探讨总结. 希望能为逐步解决上面的死循环出一点力.