Date: 12 May 2012
软件中随处可见命名。所以，命名是否得当直接关系的代码的可读性。在这一章中作者给出了一些命名的建议和规范。我记录和总结了一下自己有感触和能用的上的一些规范。
1.命名要有意义：在书中，作者给出了：名副其实、避免误导、做有意义的区分、使用读得出来的命名等建议。总结之后，发现就是要有意义，能让初次读代码和维护代码的人员明白命名的意思。作者还提出，使用便于搜索的命名，也就是说，长命名要好于短命名。
2.类名：类名不要使用动词。
3.方法名：方法名应当使用动词或动词短语。
1.函数应该短小：函数的缩进层级最好不要一层或两层。
2.只做一件事：判断函数是否只做了一件事的方法之一：看是否还能从函数中再拆分出一个函数出来。
3.每个函数一个抽象层级
4.函数参数：函数的参数越少越好，当函数的参数大于3个时，就可以考虑用其他的数据结构来代替这些参数了。
5.避免重复
重复可能是软件中一切邪恶的根源
注释最多就是一种必须的「恶」，足够好的代码不需要注释其他人也能够看懂。而且注释也不会使原本糟糕的代码变好。所以，尽量要使用代码来阐释其行为。
好的注释可有这些内容：法律信息、提供有用的信息、对意图的解释、警示和关于公用API的解释（例如Javadoc）。
而坏的注释常常会有这些内容：喃喃自语、误导性注释、日志式注释、大括号后的注释、注释掉的代码（这个可以由版本控制搞定）和非公用API的Javadoc。
垂直格式：大多数文件的行数的最大值应在200～500行（这并非是不可违背的原则）；封包声明、导入声明和每个函数之间都有空白行将它们隔开，有表示完整思路的代码也可用空白行隔开；关系密切的概念应该相互靠近；类的实例变量应该声明在类的顶部；被调用的函数应该放在执行调用函数的下面（Pascal、C和C++中则恰好相反）。
横向格式：代码行的长度的上限在100～120个字符；使用空格将关系紧密的事物连接在一起，同时也用空格把相关性较弱的事物分开；
隐藏实现关乎抽象；乱加取值器和赋值器是最坏的选择；The Law of Demeter 认为模块不应该了解它所操作对象的内部情况；诸如，ctxt.getOptions().getScratchDir().getAbsolutePath() 这类连串的调用常被认为是肮脏的代码风格，应该避免；数据传送对象DTO（Data Transfer Objects）是一种只有公共变量二，而没有函数的类，这种类一种十分简练的数据结构，通常用于数据通信。
——To be continue