闲话命名

前几天在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形螺丝的用途，让我茅塞顿开。

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