近期博客访问量提高了不少，分析了下原因，发现是有几篇近期写的文章被某个好心网友提交到dbanotes的Startup News上了。与此同时，一些反馈也随之而来。从反馈来看，《那些代码中的“中国式”命名》一文似乎受到了更多的关注，或许是文章标题比较容易引起好奇的 缘故吧。但文章的本意仅是想阐述一些事实罢了，并没有“哗众取宠”的意思。网友的观点也促使我重新对“中国式”命名做了反思。

* “中国式”命名的普遍性

我曾天真地希望该问题只是我们项目中的个例，但现实是“沮丧”的。看到评论中几个网友都反馈“中枪”，说明该命名方式似乎是普遍存在于中华大地程 序员们的代码库中的。

中国式命名归跟结底是文化差异性和表达方式的问题，就和Chinglish一样。由于中式词汇、语法结构已经成为了我们的潜意识一部分，存在与大 脑的核心层，每当 我们要命名或表达一个事物时，大多数人首先在大脑中展现的是这个事物的中文拼写方式、中文语法的结构，其次才可能是英文的（对于第一外语是英语的人），如 果想不出正确的英文名并且懒得去求 谷哥，那么该事物在程序代码中就很可能以“中国式”的命名而存在着。

* 不是所有Chinglish都是English

在再次谈“中国式”命名之前，我们先要搞清楚：“不是所有Chinglish都是English”。

Chinglish刚出现的时候，标准英语的支持者认为Chinglish是垃圾，是错误的表达，无法被接受，对其进行抨击。但万事万物都有一个 接受的过程。今天来看，越来越多的选词达意准确的Chinglish词汇以及表达方式正在被国人接受甚至被以英语为母语的人所接受而成为 English，比如近年来的热词：geilivable（给力），再比如很早之前就接受的"long time no see"等。

作为人类的优秀语言，无论是英文还是中文，都具有很强的开放性和包容性。随着时代的变迁，新生事物的出现，词汇与表达方式都是在语言间相互渗透， 相互补充的。比如随着近些年中国航天事业的迅猛发展，尤其是神舟飞船的多次成功发射，标准英语中接纳了“中国宇航员”这个词 汇：taikonaut；再比如很可能于明年被收录到牛津英语词典中的”Tuhao(土豪)”、 “Dama(大妈)”和“Hukou(户口)”等。而近些年来，一些外词的音译中文词汇也被加入汉语词典了，比如博客 （blog)、粉丝(fans)等。

但不是所有Chinglish都可以被接受而成为English的。Chinglish是良莠不齐的，那些完全错误的、让人啼笑皆非的词汇和表达 方式现在不会被接受，以后也是不会被接受的。比如下面这两个典型的错误：

    杯子 – Cup son
    开水房 – Open Water House

* 用Chinglish != "中国式"命名

既然“中国式”命名是普遍存在的，那是否是合理的呢？在上一篇文章中，我个人将其归类为bad smell一类，现在的观点依旧如此。

有人不禁要问：既然有些中国式英语(Chinglish)都能被老外所接受，那“中国式”命名为何不可呢？

我的答案如下：在代码中使用已经被老外接受了的Chinglish词汇，实际上与使用地道英文词汇本质上是相同的，算不上“中国式”命名；这里的 “中国式”命名仅针对我在上一篇文章中提到的那些命名方式，当然包括那些并未被广泛接受的Chinglish词汇和使用方法。

* 对"中国式"命名的态度

网友观点：“认真你就痛苦了”。
我倒不是这么想的。既然我们认为命名在编码过程是重要的、困难的，我们就更是要认真对待，在这方面我们有些时候真得较较真儿。我想这也是专业性的 一种体现。

* 到底该如何做？

一句话：尽可能用English（编程界主流文化在欧美，主流语言是英语，这才是根本原因），包括那些广泛接受的Chinglish。纯自造的 “词汇”，比如网友评论中提到的left_kuohao这种中英结合词还是不写为好。

如果有一天中文编程语言成为编程界的主流，那中国程序员也就不用在命名上纠结了。

众所周知，assert是程序调试阶段的一柄利器，可以帮助程序员快速的定位代码问题。但一般来说当程序部署到生产环境的时候，我们会选择关闭assert。不过由于历史原因，我们运行在生产环境下的程序中的assert依旧发挥着作用，这样一把双刃剑就悬在了我们头上。

我们用的是自己的assert实现，这个实现没有C标准库中assert实现那么普适，不过可以满足我们自己需要的功能，它在运行时可以将断言失败信息记录到文件中以便事后分析，并调用了C运行库的assert让进程退出。

在生产环境下开启assert似乎确非惯例，但这也许还谈不上对与错，更多可以看成是当时开发者们的一种选择，在“让程序带着bug继续运行”和“遭遇bug时尽早让程序退出”两者之间，他们选择了后者。当然这也可能是当时他们的一个无奈的选择：在产品诞生初期，Bug较多，为了快速在生产环境定位Bug而开启了assert。

不过时过境迁，客户对产品质量的要求越来越高，我们除了在线下通过各种方法提升产品质量外，在线上当程序出现Bug时的处理方式也要考虑做适当变化，遭遇Bug直接主动退出导致业务瞬间中断的方式被越来越多的开发人员质疑。或者现在的开发人员也是迫于一些外部压力，宁愿选择让程序带着Bug运行下去。

昨天我们针对这个问题做了一个内部讨论，考虑修改自有assert的实现，去除对C库assert的调用，只保留断言失败的信息记录。这样就不会导致程序遇Bug立即退出的情况。不过仍有一个项目组认为这种方案不能解决他们系统中遇到断言失败时无法自恢复并继续健康运行的问题，希望能在代码中感知断言失败，并对错误现场进行一些修复性处理，比如如果断言失败发生在加锁后，希望断言发生后能直接走到解锁环节。最后居然给出了一个让人哭笑不得的方案：给assert加上一个特定的返回值表示程序出现异常（多为Bug）。

先不谈给assert加上返回值有悖assert设计的初衷，如果真的给assert加上了返回值，那意味着什么呢？据不完全统计有如下几点需要改动：
1、assert的实现彻底颠覆，如果按照C标准库中对assert设计的要求，甚至可能是很难实现的；
2、你完全不能忽视assert，因为它还有返回值，甚至当断言失败时，会直接退出使用assert的那个函数；
3、大量遗留库代码和业务层代码需要判断assert的返回值以及使用assert的函数的返回值，增加对assert返回的所谓特殊错误码的处理；
4、实在想不出这个"恐怖"的想法还能带来什么改变。

对这样一个费力不讨好、不给力的想法我除了反对，还是反对。有这些时间还不如仔细琢磨一下如何提高设计能力和产品质量呢。如果非要这么做，建议放过assert吧，请重新实现一个能检查感知Bug的函数接口吧。