第一章 整洁代码
第二章 有意义的命名
-
名副其实
问题不再于代码的简洁度，而在于代码的模糊度。即上下文在代码中未被明确体现的程度。
-
避免误导
1、应当避免使用与本意相悖的词。
例如 accountList 来指称一组账号，除非他真的是List类型，List对程序员有特殊意义。所以accountGroup或者bunchOfAccounts，甚至用accounts都会好一些。
2、提防使用外形相似度较高的名称。
例如，想区分模块某处的XYZControllerForEfficientHandlingOfStrings和另一组XYZControllerForEfficientStorageOfStirngs，会花太长时间了。
-
做有意义的区分
以数字系列命名（a1,a2...）是依意命名的对立面，完全没有提供正确信息以及提供向导作者意图线索。
反面教材：
getActiveAccount()
getActiveAccounts()
getActiveAccountInfo()
-
使用读得出来的名称
-
使用可搜索的名称
-
避免使用编码
1、成员前缀
不必用m_前缀来标明成员变量。应当把类和函数做得足够小，以消除对成员前缀的需要。
2、接口与实现
取消对接口的标识I，比如IShapeFactory改为ShapeFactory。
对实现进行标识，比如ShapeFactoryImpl、CShapeFactory。
-
避免思维映射
不应当让读者在脑中把你的名称翻译成为他们所熟知的名称，这种问题经常出现在选择是使用问题领域属于还是解决方案领域的术语时。
-
类名
-
方法名
-
别抖机灵
-
每个概念对应一个词
例如在Android开发，Presenter中进行网络请求，请求方法一般叫requestXXX();那么都固定叫requestXXX(),就不要再搞一些getXXX(),acquireXXX()... 每个概念对应一个词。
-
别用双关语
避免将同一单词用于不同目的。比如add();
-
结合涉及问题的领域的名称
反例：firstName、lastName、street.....
正常：addFirstName、addrLastName、addrState...
-
不要添加没用的语境
第三章 函数
-
短小
我们常说函数不该长于1屏幕。但是具体要多小呢，不要有100行那么多，20行封顶最好。
1、代码块与缩进
if、else、while语句等，其中代码块应该只占一行，该行大抵应该是一个函数的调用语句。这样不但能保持短小，而且，因为块内调用函数拥有较具说明性的名称。
-
只做一件事（类似设计模式中的单一职责）
函数应该做一件事。做好这件事。只做这一件事。
如何判断一个函数是否只做了一件事呢？也就是说看一看，函数只是做了该函数名下同一抽象层上的步骤，则函数还是只做了一件事。
-
每个函数一个抽象层级
-
Switch/if...else...
Switch天生要做很多的事情，只写出一件事的Switch语句也很难。不过有的时候我们可以使用工厂模式，利用多态性来完成使用switch创建对象的过程，将switch对象的创建，隐藏在某个继承关系中。有的时候switch违反了开闭与单一职责原则，所以我们也要就事论事。
-
使用具有描述性的名称
Ward原则：“如果每个例程都让你感到深合己意，那么就是整洁代码。”要遵守这一原则，在于为只做一件事的小函数起个好名字。函数越短小、功能越集中、就越便于起个好名字。
别害怕长名称。
网友评论