代码整洁之道阅读笔记
Chapter 2
成员前缀
不要使用m_前缀来表明成员变量，应该把类和函数做得足够小，消除对前缀的依赖。
类名
类名和对象名应该是名词或名词短语，如Customer, WikiPage，避免使用Manager、Processor这样的类名。
方法名
方法名应该是动词或动词短语
每个概念应该对应一个词
给每个抽象概念选一个词，并一以贯之。比如若一直使用get的命名方式，就一直使用，不用出现
fetch、 retrieve之类的意思相近的命名方式。
添加有意义的语境
你需要有良好命名的类、函数或名称空间来放置名称为读者提供语境，如果不能的话，
就个名称添加前缀以创造语境。
比如，你有firstName, lastName,street之类的变量，当它们放到一块的时候，你很明显
地能够猜出这是一个地址的部分，不同当你只在一个方法内只看到firstName的时候，你能
猜到这是地址的一部分吗，所以我们要添加语境。比如把以上变量重新命名为addrFirstName,
addrLastName, addrStreet。当然最好的做法是为以上提供一个Address的类，然后把firstName，
lastName, street放入该类中。
不要添加没有意义的语境
只要短名称足够清楚，就比长名称好。比如相比于Address来说，accountAddress和customerAddress
都不是一个好的类名，同样的如果需要于MAC地址、端口地址和Web地址相区别，用PostAddress，
MAC,和URI会是个更好的选择。
Chapter 3 函数
3.1 短小
3.2 只做一件事
函数应该只做一件事
3.3 自顶向下读代码： 向下规则
代码应该有自顶向下的阅读顺序，这样查看函数列表时，就能循着抽象层级向下阅读了
3.4 对于switch语句
使用多态替换switch语句。
3.5 使用描述性的名称
- 记住沃德原则：“如果每个procedure都让你感到满意，那就是整洁代码”
- 函数越短小，功能越集中，也更容易取个好名字。
- 别害怕长名称。长名称有更强的描述性，要比短而费解的名称好，长而具有描述性的名称，要比具有描述性的长注释好。
- 别害怕花时间取名字，你应该尝试不同的名称，实测其阅读效果，直到找到最有描述性的
那个。 - 选择具有描述性的名称能理清你关于模块的设计思路，并帮你改进。追索好名字，
往往导致对代码的改善及重构。 - 命名方式要保持一致。使用与模块名一致的短语、名词、和动词给函数命名。
3.6 函数参数
- 最理想的参数数量是0个，其次是1个，再次是2个，应该尽量避免3个参数。有足够的理由
才能使用3个以上的参数。 - 应该尽量用一些机制将2元函数转变为1元函数。
- 如果函数看来需要2个、3个、或3个以上的参数，就说明其中一些参数就该封装为类了。
比如下面的两个声明。
Circle makeCircle(double x, double y, double radius);
Circle makeCircle(Point center, double radius);
3.9 使用异常代替返回错误码
比如，有时候要判断很多东西，然后再返回错误代码。
if (.........)
{
if (......)
{
logError(..............);
}
else
{
logError(..............);
}
}
else
{
logError(..............);
}
但如果使用异常替代返回错误码，就能把错误处理简化，并把错误处理从主要的代码中分离出来。
try {
............
...........
} catch(Exception e) {
logError(e.getMessage());
}
需要记住，函数应该只做一件事，所以logError函数中，应只做错误处理。
3.10 别重复代码
3.12 如何写出这样的函数？
我写函数时，一开始都冗长而复杂，有很多缩进和嵌套，有过长的参数列表。名称也是随便起的，也会有重复的
代码，不过我会配上一套单元测试。
然后，我打磨这些代码，分解函数，修改名称，消除重复，有时还拆分类，同时保证测试通过。
最后，遵循本章列出的规则，组装好这些函数。
我并不从一开始就按照规则些函数。我想没人能做得到。
Chapter 4 注释
- 当我们不能表达我们的代码意图时，这时我们才用注释去表达。
- 只有代码才能忠实地告诉你它做的事，那是唯一的真实来源。所以，尽管有时也要注释，但是
我们也该多花心思尽量减少注释量。
4.1 注释不能美化糟糕的代码
带有少量注释的整洁有力的代码，要比带有大量注释的零碎而复杂的代码好得多。
4.3 什么是好注释？
真正好的注释是你想办法不去写的注释。
- 法律信息： 比如与版权及著作声明
- 提供信息的注释，这类注释有时管用，不过更好的方式是尽量利用函数名称传达信息。
- 代码作者对意图的解释
- 阐释： 通常更好的方法是尽量让参数或返回值本身就足够清楚，单如果参数或返回值
是某个标准库的一部分，或是你不能修改的代码，着帮助阐释其意义就会有用。比如：
........
assert(a.compareTo(a) == 0) // a == a
assert(b.compareTo(a) == 1) // b > a
.........
- 警示： 比如，用于警告其他程序员小心修改或调用这个代码。
- ToDo注释： ToDo注释是一种程序员认为应该做，但由于某些原因目前还没做的工作。
// ToDo method
protected VersionInfo makeVersion() throws Exception {
return null;
}
4.4 坏注释
大多数注释都是此类。通常坏注释都是糟糕的代码的支持或借口，或者对错误决策的修正。
- 如果决定写注释，就要花必要的时间确保写出最好的注释
- 多余的注释。如果变量名已经命名的足够表示你的意图，为什么还要添加多余的注释呢，
多余的注释不如代码精确，也会误导读者接受不精确的信息，而不是理解代码。
多余的注释会把代码搞得含糊不明。 - 误导性的注释。 有时，注释写得不够精确，导致读者对某一函数进行的错误的使用。
- 循规性注释。 所谓每个函数都要有Javadoc或每个变量都要有注释的规矩全然是可笑的，
这类注释只会让代码变得散乱，令人迷惑不解。 - 日志性注释， 废话注释，括号后面的注释。
- 能用函数或变量名清晰的表达就不要用注释。
- 位置标记。有时，程序员喜欢在源代码中标记某个特别位置（尽量少用标记栏，
只在特别有价值的时候使用）。比如
// Actions /////////////////////////////////////////////
- 由于现在源代码控制系统很强大了，所以不需要在代码前加上自己的名字或者保留注释掉的代码。比如
/* Added by Rick*/
// InputStream resultsStream = formatter.getResultStream();
// StreadmReader reader = new StreamReader(resultStream);
