《Clean Code》读书笔记

翻网站想买书的时候看到了这本书，毅然决然的买了。那时候我正要准备写我毕业设计的程序。

这本书提到了很多关于编程上需要注意的点，觉得有些地方很有用所以想整理出来供大家参考也方便我以后复习。

书中讲了很多编程上注意的细节。不过这些细节还是需要自己长期代码的积累，如果目前还没有自己的代码风格，那可以依照这本书的建议多加练习积累。但是如果自己已经有一套代码风格，那也没有必要非要跟着作者的那一套来。尽信书不如无书... 

下面是我的整理的内容

第二章 命名

名副其实

好的命名应该告诉你，它为什么会存在，它做什么是，应该怎么用。如果命名需要注释来补充，那就不是名副其实。

注意命名，而且一旦发现有更好的名称，就换掉旧的

例如：

Int d; // 消逝的时间，以日计

 

改为

Int elapsedTimeInDays;

 

做有意义的区分

废话都是冗余的。Variable 一词永远不应当出现在变量名中。Table一词永远不应当出现在表名中。NameString会比Name 好嘛？难道Name会是个浮点数不成？

缺少明确的规定，变量moneyAmount 就和money没区别，customerInfo与customer没区别，accountData与account没区别，theMessage也与message没区别。 要区分名称，就要以读者能鉴别不停之处的方式来区分。

这部分是我尝尝不注意的地方，很容易把命名搞的冗长。

 

使用读的出来的名称

作者举了下面这个例子

变量名为 genymdhms（生成日期，年月日时分秒）

改成下面这个可能更加易于理解

generationTimestamp

 

类名: 名词或者名词短语

方法名: 动词或者动词短语

 

每个概念对应一个词，并且一以贯之

如 fetch、retrieve、get来给多个类种的同种方法命名

 

使用解决方案领域名称

因为只有程序员才会读你的代码，所以尽管使用术语、算法名、模式名、数学术语。

使用源自所涉及问题领域的名称，这样负责维护代码的程序员就能请教专家了

 

添加有意义的语境

假设有firstName、lastName、street、houseNumber、city、state、和zipcode的变量。当它们在一块的时候，很明确的构成了一个地址，但是假使只是在某个方法中看见的孤零零一个state变量时，你就可能不知道是什么信息了。所以这里可以添加一个前缀addrFirstName、addrLastName、addrState等。当然最好是创建名为Address的类。

 

------

函数

3.1 短小

函数的第一规则是要短小，第二条规则是还要更短小。

每行最多不能超过150字节

函数也不应该有100行那么长，20行封顶最好。

代码块和缩进

If 、else、while等语句其中的代码块应该只有一行，该行大抵应该是一个函数调用语句。这样不但能保持函数短小，而且，因为快内调用的函数拥有较具说明性的名称，从而增加了文档上的价值。

这也意味着函数不应该大到足以容纳嵌套结构。所以函数的缩进层级不应该多于一层或两层。当然，这样的函数易于阅读和理解。

 

3.2 只做一件事

函数应该只做一件事。做好这件事。只做好这一件事。

3.3 每个函数一个抽象层级

自顶向下读代码：向下规则

3.5 使用描述性的名称

长而具有描述性的名称，要比短而令人费解的名称好。

长而具有描述性的名称，要比描述性的长注释好。

命名方式要保持一致。使用与模块名一脉相承的短语、名词和动词给函数命名。

3.6函数的参数

最理想的参数数量是零（零参数函数）其次是双参数函数，尽量避免三参数函数，有足够特殊的里有才能用三个以上的参数（多参数函数）

 

参数对象：如果函数需要两个、三个及三个以上的参数时，就说明其中一些参数应该封装成类了。

如：

Circle makeCircle (double x, double y, double radius);

Circle makeCircle (Point center, double radius);

 

3.6.7 函数与关键字

对于原函数和参数应当形成非常好的动词/名词对形式

write(name) 已经足够让人能够理解了，不过更好的是writeField(name)它告诉我们name是一个 field

assertEqual改成assertExpecedEqualsActual(expected,actual)就会好一些，这大大减轻了记忆参数顺序的负担

3.8 分隔指令与询问

函数要么做什么事，要么回答什么事，二者不可兼得。函数应该修改某对象的状态，或是返回该对象的有关信息。两样都干常会导致轮乱。

如： public boolean set(String attribute, String value)

 if(set("username","unclebob"))…

由于返回是布尔值容易引起歧义 不明确是判断是否存在还是判断是否set 成功。

作者本意，set是个动词，但是在if的上下文中，感觉他是个形容词。

解决方案吧指令与询问分割开来，防止混淆

If(attributeExists("username")){

setAttribute("username","unclebob")

}

 

3.9

抽离try/catch 代码块

try{

    deletepage(page);

    registry.deleteReference(page.name);

    configKeys.deleteKey(page.name.makeKey());

}

catch (Exception e){

    Logger.log(e.getMessage())

}

Try/catch代码搞乱了代码结构，把错误处理与正常流程混为一谈，最好把try和catch 代码块的主体部分抽离出来，另外形成函数。

	public void delete(Page page){
		try{
			DeletePageAndAllReferences(page);
		}
		catch (Exception e){
			logError(e)
		}
	}
	
	private void deletePageAndAllReferences(Page page) throws Exception{
		deletepage(page);
		registry.deleteReference(page.name);
		configKeys.deleteKey(page.name.makeKey());
	}
	private void logError(Exception e){
		Logger.log(e.getMessage())
    }

 

函数是语言的动词，类是名词。大师级的程序员把系统当成故事来讲。

 

第四章注释

注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释是一种失败。我们总无法找到不用注释就能表达自我的方法，所以用药有注释，这并不值得庆贺。

因为注释容易撒谎，程序员不能坚持维护注释，因此在代码改变的情况中，注释没有随之变动，不能总是跟着走。所以只有代码才是唯一真正准确的信息来源。监管有时也需要注释，我们也应该多花些心思尽量减少注释量。

 

好注释

法律信息，例如版权著作权声明 如// Copyright © XXXX

提供信息的注释

// return an instance of the Responder being tested

Protected abstract Responder responderInstance()

对意图的解释

阐释：把晦涩难懂的参数或者返回值的意义解释成某种刻度的形式

assertTure(a.compareTo(a) == 0 ) // a==a

assertTure(a.compareTo(b) != 0 ) // a!=b

 

警示:用于警告其他程序员会出现某种后果的注释

// don’t run unlesss you have some tome to kill

Xxxxxx  your code

TODO 注释：程序员认为应该做，但是由于某些原因还没做的工作

放大：注释可以放大某种看起来不合理之物的重要性

 

坏注释

这部分就略过了主要记住什么时候值得写注释就好。

 

第五章 格式

空白行分开概念

有联系的药紧凑

变量声明尽可能靠近使用位置

循环中变量声明在循环中。for(int i = 0 ; i<10; i++)

实体变量在类的顶部声明

某个函数调用了另一个，把它们放在一起，调用者在被调用者上面

概念相关的代码在一起

横向不超过120字符

空格分隔 如 return b*b  -  4*a*c 就比 return b*b-4*a*c 读起来更舒服

用同一种风格编程： 同一个团队使用团队约定的编程风格