前几天在Twitter上有朋友问:ln的参数顺序要怎么记忆比较好,因为总是搞错。这个问题我也遇到过,以前每次都记不住两个参数的先后顺序,最终办法是花了点时间背诵命令模板,每次用到时心里默念就好了:

ln option target linkname

我没想到的是,搞混顺序竟然是个普遍问题,我本来以为哪怕有疑问,背背模板也好了,大家都应该是如此。仔细了解才发现,有疑问的朋友确实背下了OS X中的man,但这份文档写的是:

ln source_file target_file

看起来区别不大,用起来差别不小。因为做链接时,target既可以指“被链接的对象”,又可以指“生成的链接名”,和source_file之后就更容易混淆了。参与讨论的几位推友都认为我背的模板更好用(其实是我的运气更好,背诵时遇到了写得清楚的文档),因为另一个参数名是linkname,意义非常明确,所以哪怕target的意义和OS X中的完全不同,也不影响理解和使用。

借着这个机会,我想说说命名的事情。许多人把命名看成小事一桩,只是一个符号,或者贴一个标签,但事实并非如此,因为名字(或者说符号、标签)会影响大家的认知,如果命名难以理解或者容易混淆,可能造成严重的影响。这一点,我有亲身经历。

再举个例子,写程序时需要给变量命名,许多程序员在取名时并没有太多的考虑,“重量”就是weight,“长度”就是length,“时间”就是time,这是常见的做法。如果只是独自开发的简单系统,估计并没有问题,但如果系统复杂一点,需要多人协作开发,这样“偷懒”的命名方式就成了噩梦:不同的开发人员经常需要沟通、比对,以确认“重量”的单位,到底是克,还是千克,还是英磅……按照我的痛苦回忆,这样的系统,维护和开发起来无比麻烦,开发人员不得不经常停下“干正事”的脚步,去明确这类变量的单位。终于有一天我们忍受不了了,专门抽出时间为变量重新命名,比如weightInGram、weightInKG、weightInPound、lengthInCM、lengthInMeter、timeInSecond等等,才彻底解决这个问题。

其实,命名的规范问题,不少编程书籍里都会讲到并强调,但很多程序员并不重视,由此也产生了非常严重的后果:1999年美国宇航局(NASA)的火星气象卫星(Mars Climate Orbiter)任务失败,就是因为一组工程师的程序使用公制单位,另一组却使用英制单位——我斗胆猜测,相比纠正美国人民历史悠久的“英制”传统,赋予程序变量清楚的命名,也许可以更有效地预防此类错误?

上面说过,命名不只是贴个标签那么简单,而会影响大家的认知,所以命名的问题当然不限于程序开发,而会深入到生活的各个方面。前些年有本讲设计的书叫做《Don’t make me think》,强调是说设计要符合直觉,不要给使用造成障碍。这个目标大家都认可,也为此在设计的各个方面投入了心血,但命名不当,这些工作很可能大打折扣。

有人就指出,点点网照抄tumblr时,把帮助用户推荐内容的“radar”功能直接命名为“雷达”,但中文用户见到“雷达”怎么可能想到这是帮自己推荐内容的呢?

类似的还有QQ邮箱写邮件界面的“关闭”按钮,我估计这是直接从Discard翻译过来的,它的意思是“放弃当前的内容”(MIUI里好像叫“舍弃”)。“关闭”这个命名也有些问题,因为我每次点之前,都要想想这是不是直接关掉整个页面(也就意味着退出了当前登录)。如果按照生活习惯改名为“作废”,是不是更形象更符合直觉呢?

有些人说,好的命名确实重要,但找到好的命名没那么容易,比如现在许多概念是从国外传过来的,中文里找不到对应的概念。不过照我看,有些情况下这说法成立,但不是每种情况都可以这么辩解,真正的原因还是偷懒或者考虑不周。名字或许可以从外国传进来,大家生活的内容却没有那么大的差别。举个例子,熟悉机械的人都知道有种螺丝是U形的,一般用来固定管、柱等等构件,如今说“U形螺丝”大家都能理解,但这个零件早就有了,在普通人(尤其是普通工人)并不熟悉英文字母的年代,它叫什么名字呢?这个问题我百思不得其解,有天遇到一位老师傅才明白——它叫“骑马螺丝”,这个名字既形象,又切合U形螺丝的用途,让我茅塞顿开。

不要觉得“骑马螺丝”这种命名很土,它确实有利沟通(尤其是对不认识英文的用户而言),即便今天看起来老土了,当年这个命名确实方便了理解和沟通——如果命名就是贴标签,那么合适的标签也比不合适的标签更好。而且,想到这种命名往往还需要一点机缘:我小的时候,每次回外婆家过夜,因为没有多余的床,只能在很窄的沙发床上挤两个人睡,而且必须有一个人“倒过头”来睡,有一次我忽然说:噢,这不就是装电池式睡觉嘛。