今日洞见 文章作者、部分图片来自ThoughtWorks：黄博文
本文封面来自网络
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表
已经本网协议授权的媒体、网站，在使用时必须注明”内容来源：ThoughtWorks洞见”，并指定原文链接，违者本网将依法追究责任
Martin Fowler曾经在一篇文章中引用过Phil Karlton的话： There are only two hard things in Computer Science: cache invalidation and naming things. 他说这句话在很长的一段时间内都是他最喜欢的话，可见命名对于广大程序员来说的确是个大问题
对于我们中国人而言，问题可能出在两个方面： • 自打学编程开始就没被教育过要重视命名
这个问题在谭浩强所著的《C语言入门》一书中可见一斑
这本书可以说是大多数程序员的大学入门教材，但本书通篇都是各种a,b,c以及x,y,z的命名方式
这种poor naming的方式被广大程序员纷纷效仿，导致如今大多数项目代码都充斥着诸如此类的命名
• 命名需要一定的英文功底，而国内程序员的英文水平参差不齐
很多程序员被教育后开始逐渐重视命名，但是自身英文水平有限，不知道该如何选取合适的英文词汇来进行命名
有的甚至直接将中文译成英文，抑或是用拼音来进行命名，这样反而适得其反
关于命名的重要性，我想不需要过于强调
如今的软件开发已经脱离了求伯君那种单枪匹马的时代，你写下的每一行代码都会在日后被团队成员甚至自己多次查看
如果是个开源项目，那么更会被全球各地的人查看源代码，所以代码的可读性就显得尤为重要
如果读者能够轻松从代码中读出你的意图，那么就说明你的命名功底相当扎实
比如在一个管理系统中，你使用这样的代码： a = b * c; 这很容易让人摸不着头脑，虽然程序能够正常运作，但恐怕没人敢轻易修改这行他们不了解的代码
而如果修改成为这样： weekly_pay = hours_worked * pay_rate; 那恐怕极少有人不懂这行代码的意图
糟糕的命名也会导致大量无谓的注释，这是一个很容易跳进去的陷阱
在编写下一段代码时，为避免别人不明白代码的含义而加上注释，这貌似是一个很精妙的想法，实际上却南辕北辙
比如以下的注释： int d; // elapsed time in days; 貌似很容易让人读懂，但是问题还是很多
首先注释不能跟着所有的引用，在定义处了解了“d”的含义，继续往下看的话却很容易忘记
其次，在更新代码时很可能会忘记修改注释，反而给把读者带入歧途
与其用这样的注释，还不如直接重命名： int elapsedTimeInDays; 这样清晰易懂，还不用维护注释，何乐而不为？ 那么如何着手来提高的自己的命名技巧呢？ 首先寻找一份公认的代码规范，并严格按照这样的标准执行
比如Google开源了自己内部使用的语言编码规范，我们可以直接拿来使用，Google Java中的style guide对此作了详细的介绍，除此之外还有C++等
这里收集了Google对各种语言的编码规范，非常具有参考价值
标准代码规范中的每一条都有胜出的理由，值得我们遵从
但某些命名问题不一定只有一种最好的解决方式，这就需要与团队成员共同协商
比如对于Java单元测试类的命名方式，不同的团队可能不一样：有的团队喜欢以should开头，有的喜欢以test开头；有的喜欢用骆驼命名法，有些喜欢用下划线命名法
每种方式都有各自的利弊，没有一种能完全脱颖而出，因此团队要根据实际情况来制定规则
一旦确定使用某一种，那么一定要保持一致
某些命名规范其实是可以进行自动化检查的，比如在Java应用的构建过程中可以引用“CheckStyle”这款插件，对命名进行一些基本的检查，比如方法名、变量名是否遵循了一定模式等
这样在一定程度上可以强制大家遵守某些约定
关于这类问题，自己以前也曾写过一篇文章，请参见 http://www.huangbowen.net/blog/2013/06/21/introduce-checkstyle/
最后要在团队中建立起code review的机制，通过code review来相互监督、纠正命名问题，而且这样更容易在命名约定上达成一致，方便协作开发
Code review可以采取非正式会议评审的方式：最简单的方式就是每天找个固定时间把大家一起聚在一个显示器前，review每个人的代码，现场提出问题，当事人记录下来会后更改 ， 这种方式非常高效
另外，有的团队在嵌入代码时可能会引入一些代码评审机制，比如pull request、cherry pick等
这种review方式比较重量级，反馈周期也较长，好处是可以保证最终嵌入的代码是没有问题的
很多语言和框架为了增加可读性，都把命名玩出花来了
比如JavaScript生态圈中重要的单元测试工具Jasmine把测试函数以“it”命名，这样可以与参数连接起来成为一种表意的自然语言： 总之，命名问题只是整个编码规范中的一小部分，但是起的作用举足轻重，它是判断一个程序员是否专业的必要标准
– 小编推荐 – 《从敏捷转型到精益企业》 HOT!!! 《大象转身，一蹶不振还是华丽重生？》 《不一样的互联网玩法—上海华瑞银行“极密”》 HOT!!! 本周末社区活动： 成都 & 西安 回复201501-201512，获取当月精彩洞见合辑 如：想看5月精彩洞见合辑，请回复 201505 若你想去 TW洞见网站阅读所有洞见文章，复制网址在浏览器打开： insights.thoughtworkers.org ThoughtWorks ❶ 新版技术雷达 ❷ 各类干货洞见 ❸ 精选职位信息 ❹ 活动预告总结 长按右侧二维码快速关注~ 阅读原文内容 & 文中 蓝色字体 对应链接请点击【阅读原文】