<1> 导读 && 函数（方法）篇

早就想看下《clean code》了，不知为啥总是没看，突然发现该看看了。其实很多原则或多或少都听说过实践过。再来看一下可能感觉更好吧。
窃以为这本书第一章算是整洁之道，后面算是整洁之术吧。

一、 代码整洁之道

代码永存，没有什么先进的代码工具能代替程序员。模糊的需求和精确的代码之间有个必须程序员才能弥补的鸿沟。

勒布朗法则：later equals never.  法则好简单，为什么做起来那么难呢？？有的洁癖真的很吸引人。

花时间保持代码整洁不仅关系效率而且关系生存。破窗理论，破烂的代码是毁灭的第一步。

当老系统繁重的无法快速满足新变化时，重启新团队重新设计老系统，并与老系统并行运行的例子还是有一定的体会的，此事正好发生在我待过的项目。

写了不整洁的代码而因此承受惨重代价，这是程序员自作自受，跟繁琐的需求，无止的变化，难以接受的进度，sx的经理都有关系，但还是要说，自作自受。

写混乱的代码就是最快的方式？ 不是，那是因为你根本写不出漂亮的代码。漂亮的代码才是最快的。你有洁癖吗？艺术家的艺术。

整洁的代码只做好一件事。尽可能的简单（如命令查询分离原则），尽可能的少依赖。
简单的代码，依其重要顺序：
1. 能通过所有测试
2. 没有重复代码
3. 体现系统中的全部设计理念
4. 包括尽量少的实体，比如类，方法等。

消除重复和提高表达力（命名）能在代码整洁方面获益良多。

不要重复代码，只做一件事，表达力，小规模抽象。概括了整洁代码的全部内容。

写新代码时我们一直在读旧代码。读写话费时间比例超过10：1。编写代码的难度，取决于读周边代码的难度。要想写的容易，先让代码易读吧。

美国童子军军规：让营地比你来时更干净。代码的每次check out, check in也是如此。

二、 代码整洁之术
2.1命名

1.名副其实，见名知意。
1） 名字不要怕长，表达清楚更关键。
2） 魔鬼数字用有意义的常量
3） If里的条件能用一个有明确含义的功能方法表达更好。

到处需要命名
如：原始代码，



重构后代码1：


再次重构后2：


2.做有意义的区分

比如有两个类，ProductInfo, ProductData，名称虽然不同，但意义却无区别，就像a, an, the一样。这种情况在项目中也时常发生，至少我经历过。。。

3.使用读得出来的名称
使用正确的准确的英文表达。花些时间在命名上是非常值得的。不然，痛苦在后面...
单字母名称(如i,j)只应出现在短方法的本地变量。名称长度应与其作用域大小想对应。
若变量或常量多次出现在代码中，应赋予其便于搜索的名称。比如，
原始代码：



重构后后:



4.类名

类名和对象名都应该是名词或名词短语，如Customer, Account,AddressParser。类名不应该是动词。

5.方法名

方法名应该是动词或动词短语，如postPayment, save等。

6.每个概念对应同一个词，一致的风格

每个类中采用一致的命名风格，如get***，set***，一词一意，以免概念模糊。可以采用通用的专业性的计算机术语，或问题领域的名称

7.添加有意义的语境

比如添加前缀，lastName, firstName在表示的是地址的时候就可以用addrLastName,addrFirstName.但也不要添加无意义的前缀。

命名一定要精确。

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

If,else,while等代码块中的代码应该只有一行，大抵应该是一个函数调用，一个有较具说明性的名称的函数调用。当然有些极端，理念就是不做多余的事，做同一个抽象层次的事。

2.只做一件事，做好一件事
做的事跟函数名称对应。一个函数做的事情越少，功能越集中，越好命名。

3.每个函数一个抽象层级
函数中的每个语句，包括函数调用等应该是同一个抽象层次的。

4.函数的参数
最理想的参数个数是零，其次是一，再次是二，应该避免三个。有些公司规范是不要超过5个。当参数个数要超过2个或3个时，就要看这些参数是否需要封装成类了。
尽量使用返回值，不要使用输出参数。

5.标识参数（boolean参数）




6.使用异常代替错误返回码
我们要command-query分离，但有时候command会需要返回操作的结果，这时候可以用异常表示错误，否则表示正确，不需要再返回结果状态。

7.分隔指令和查询（command-query分离）

8.抽离try/catch块
Try/catch块搞乱了代码结构，可以把处理异常的逻辑抽离成一个函数，错误处理就是一件独立的事。

9.do not repeat yourself
重复可能是软件中一切邪恶的根源。

整洁的代码并不是一开始就能写出来，就像文章的初稿一样可能混乱不堪，但经过反复重构慢慢就形成了整洁的代码。这个重构不能隔太久，重构在平时。同时保证测试通过。重构和测试总是分不开的。

评论

1 楼 穿山丁 2013-09-03  

关注楼主很久了，楼主思路清晰，读了之后收获很大，一起进步！