最近在读一些书，想和大家分享下读书的乐趣和学到的知识。目前读书的系列大都是专业相关的，例如《Clean Code, 《Refactoring-Improving the design of the existing code》, 《Pro-Objective-C Design Pattern for iOS》等等(有些是重读)。当然还有《out of control》这类午后读物。多读书，多看报，提升自己，排解寂寞。
这篇我们来分享读《Clean Code》(代码整洁之道)第二章节的读后感。
第二章节讲的事Meaningful Names, 意思是在我们写代码时，需要用到有意义能自我解释的命名方式。这部分内容不涉及技术，但是可以帮助我们写出能让他人和未来的自己读懂的代码。我会结合书中的标准和我写iOS程序的经验来批判的接受和修改一些书中的内容。
Use Intention-Revealing Names(使用'顾名思义'的名称)
这个很好理解，在我们写程序的时候，无论变量，函数，参数，类等的名称，都应该遵循这个标准。因为它可以很好地帮助你，或者其他程序员理解你的程序，理解你的变量或代码片段的目的。下面是书中的例子:
public List getThem() {
List list1 = new ArrayList();
for (int[] x : theList)
if (x[0] == 4)
list1.add(x);
return list1;
}
这段代码是干什么的呢？其实细细去读也不难发现这就是将某个list中值为4的数组加入另一个list(其实就是筛选的功能)。但是这样的代码让人很头疼，我在工作中也最烦遇到这样的代码，一般来说，只有很抽象的算法代码才会写成这样。阅读者会对这类代码产生很多问题，例如:
- theList到底是干嘛的，包含什么?
- x[0]是什么，包含什么？
- 4又代表什么?
- list1返回后怎么用？
下面是改良版的程序:
public List getFlaggedCells() {
List flaggedCells = new ArrayList();
for (int[] cell : gameBoard)
if (cell[STATUS_VALUE] == FLAGGED)
flaggedCells.add(cell);
return flaggedCells;
}
重命名之后，我们可以轻易看出这估计是个(国际)象棋游戏，标记位的cell被取出。
Avoid Disinformation (避免虚假命名)
一言以蔽之就是不要使用那些会混淆代码理解，或者错误的命名。例如不要和系统的关键字重复或特别相近, hp,aix,sco这类的前缀或者变量名不可使用，因为这是UNIX
系统内部名称。还有就是在命名一些特定数据结构时要谨慎，例如你有一对account，你可以命名成 bunchOfAccounts 或者 accountGroup 抑或accounts.书中不建议使用accountList，除非它真的是一个list结构。对此，仁者见仁，智者见智了。因为看你代码的也都是程序员，这样命名个人觉得是可以的，注意不要把Array命名成List。书中还举了一个'awful'的例子，就是用大写的'L'和'O'做变量名，类似hot key。要知道'O'和'0'是很像的，所以轻易不要用。
Make Meaningful Distinctions(命名要做有意义的区分)
不同的变量要用不同的名称区分开来。相信不少同学在命名的时候都用过a1,a2,a3这样的变量名。这并不好。一些noise的数字不应该出现在本应有意义的名称中，因为这样根本体现不出作者的意图。其实呢，在平常写一些测试程序的时候，可以图简便，这样写写。但是到了项目中，一定要用可区分的名称。书中还举到一个例子我觉得很不错, 如下:
getActiveAccount();
getActiveAccounts();
getActiveAccountInfo();
说实话，我真的不知道用哪个函数来读取账户信息了，这就是典型的区分度做的不够。
Use Pronounceable Names(用能读出来的名字)
这个没什么可说的，上个例子。genymdhms这个变量是干什么的？其实它是代表一种类型的Date，年月日-时秒分，gen代表generate。KK，挺复杂的。改成generationTimestamp就好些了。
Use Searchable Names(使用可搜索的名称)
我们为什么总强调合理的命名呢？为什么要大家都遵循命名的规范呢？其实无非是想形成一个约定俗成的习惯，让大家都能进行标准化的开发罢了。当我接手一个项目，当我想找网络模块某个功能的时候，我会去想之前的developer会用什么名字命名，例如login部分，register部分等等。这也方便之后的人去查找代码位置。但如果你命名了一个a3, b4，那查找起来就很吃力了。原书中的例子是:MAX_CLASSES_PER_STUDENT和7哪个好查找？不用说，当然是第一个。
Avoid Encodings(避免编码化命名)
这个其实遇到的情况不多，除非你是写底层的(Windows C API). 编码化命名指的是在name中加入数字，范围等信息的命名方式。最典型的就是匈牙利命名法。这种命名需要每个新加入的成员好好学习上一番，而且需要更长时间来适应它。具体的匈牙利命名是怎么回事就不在这里多说了，大家可以看这里。
Avoid Mental Mapping(避免心理地图式命名)
每个程序员都有可能使用一些shortcut(快捷方式)来命名一些长些的名称，例如用r代替url, co代替commit等等。这种命名当然不好，在项目中不要用。
Class,Method Names(类和方法的命名)
类命名要用名词性质的词，例如Customer, WikiPage,而且第一个字母要大写。原书中说道类名中不要出现动词，例如Manager, Processor, Data, 但个人觉得此条并不能让我信服。举例来说，GFTRequestManager可以让我很快意识到这是一个控制网络请求的单例控制类，而且不会和XXXRequest(某个特定请求)重复。至于函数名称，基本要包含动词了，例如postNotification这些。
Don't be cute and pun(别犯傻和用双关语)
不要使用你自己觉得很可爱其实很傻的命名，例如HolyHandGrenade, 老老实实用deleteItems代替。双关语就不多说了，别让人理解错就行。
剩下的部分就是告诉我们也可以添加一些context帮助理解，例如注释，不过不要让你的注释成为累赘，必要的时候再添加。