早就想看下《clean code》了，不知为啥总是没看，突然发现该看看了。其实很多原则或多或少都听说过实践过。再来看一下可能感觉更好吧。
窃以为这本书第一章算是整洁之道，后面算是整洁之术吧。
[b]一、 代码整洁之道[/b]
代码永存，没有什么先进的代码工具能代替程序员。模糊的需求和精确的代码之间有个必须程序员才能弥补的鸿沟。
勒布朗法则：later equals never. 法则好简单，为什么做起来那么难呢？？有的[b]洁癖[/b]真的很吸引人。
花时间保持代码整洁不仅关系效率而且关系生存。破窗理论，破烂的代码是毁灭的第一步。
当老系统繁重的无法快速满足新变化时，重启新团队重新设计老系统，并与老系统并行运行的例子还是有一定的体会的，此事正好发生在我待过的项目。
写了不整洁的代码而因此承受惨重代价，这是程序员[b]自作自受[/b]，跟繁琐的需求，无止的变化，难以接受的进度，sx的经理都有关系，但还是要说，自作自受。
写混乱的代码就是最快的方式？ 不是，那是因为你根本写不出漂亮的代码。漂亮的代码才是最快的。你有[b]洁癖[/b]吗？艺术家的艺术。
[color=red][b]整洁的代码只做好一件事。尽可能的简单（如命令查询分离原则），尽可能的少依赖。[/b][/color]
简单的代码，依其重要顺序：
1. 能通过所有测试
2. [b]没有重复代码[/b]
3. 体现系统中的全部设计理念
4. 包括尽量少的实体，比如类，方法等。
消除重复和提高表达力（命名）能在代码整洁方面获益良多。
[b]不要重复代码，只做一件事，表达力，小规模抽象。概括了整洁代码的全部内容。[/b]
写新代码时我们一直在读旧代码。读写话费时间比例超过10：1。编写代码的难度，取决于读周边代码的难度。要想写的容易，先让代码易读吧。
美国童子军军规：让营地比你来时更干净。代码的每次check out, check in也是如此。
[b]二、 代码整洁之术[/b]
[b]2.1命名[/b]
[b]1.名副其实，见名知意。[/b]
1） 名字不要怕长，表达清楚更关键。
2） 魔鬼数字用有意义的常量
3） If里的条件能用一个有明确含义的功能方法表达更好。
到处需要命名
如：原始代码，
[img]http://dl2.iteye.com/upload/attachment/0088/9143/fc901943-cb3e-3404-a068-fd16396c0f10.bmp[/img]
重构后代码1：
[img]http://dl2.iteye.com/upload/attachment/0088/9145/1aade47b-c79b-3769-ba4d-f26de0b710bc.bmp[/img]
再次重构后2：
[img]http://dl2.iteye.com/upload/attachment/0088/9149/685d1ebd-4266-352e-b412-398cb419930e.bmp[/img]
[b]2.做有意义的区分[/b]
比如有两个类，ProductInfo, ProductData，名称虽然不同，但意义却无区别，就像a, an, the一样。这种情况在项目中也时常发生，至少我经历过。。。
[b]3.使用读得出来的名称[/b]
使用正确的[b]准确的英文[/b]表达。花些时间在命名上是非常值得的。不然，痛苦在后面...
单字母名称(如i,j)只应出现在短方法的本地变量。名称长度应与其作用域大小想对应。
若变量或常量多次出现在代码中，应赋予其便于搜索的名称。比如，
原始代码：
[img]http://dl2.iteye.com/upload/attachment/0088/9154/435513fb-8841-376c-8dc9-7ac56d03cfd3.bmp[/img]
重构后后:
[img]http://dl2.iteye.com/upload/attachment/0088/9156/e64a841a-bc6f-3e86-b6af-151f6d75f225.bmp[/img]
[b]4.类名[/b]
类名和对象名都应该是[b]名词或名词短语[/b]，如Customer, Account,AddressParser。类名不应该是动词。
[b]5.方法名[/b]
方法名应该是[b]动词或动词短语[/b]，如postPayment, save等。
[b]6.每个概念对应同一个词，一致的风格[/b]
每个类中采用一致的命名风格，如get***，set***，一词一意，以免概念模糊。可以采用通用的专业性的计算机术语，或问题领域的名称
[b]7.添加有意义的语境[/b]
比如添加前缀，lastName, firstName在表示的是地址的时候就可以用addrLastName,addrFirstName.但也不要添加无意义的前缀。
命名一定要精确。
[b]2.2 函数[/b]
[b]1.函数的第一规则是短小，第二规则是还要更短小。[/b]
If,else,while等代码块中的代码应该只有一行，大抵应该是一个函数调用，一个有较具说明性的名称的函数调用。当然有些极端，理念就是不做多余的事，做同一个抽象层次的事。
[b]2.只做一件事，做好一件事[/b]
做的事跟函数名称对应。一个函数做的事情越少，功能越集中，越好命名。
[b]3.每个函数一个抽象层级[/b]
函数中的每个语句，包括函数调用等应该是同一个抽象层次的。
[b]4.函数的参数[/b]
最理想的参数个数是零，其次是一，再次是二，应该避免三个。有些公司规范是不要超过5个。当参数个数要超过2个或3个时，就要看这些参数是否需要封装成类了。
[u]尽量使用返回值，不要使用输出参数。[/u]
[b]5.标识参数（boolean参数）[/b]
[img]http://dl2.iteye.com/upload/attachment/0088/9152/7ba4ac68-78e1-37d6-9d35-e84b675e5723.bmp[/img]
[b]6.使用异常代替错误返回码[/b]
我们要command-query分离，但有时候command会需要返回操作的结果，这时候可以用异常表示错误，否则表示正确，不需要再返回结果状态。
[b]7.分隔指令和查询（command-query分离）[/b]
[b]8.抽离try/catch块[/b]
Try/catch块搞乱了代码结构，可以把处理异常的逻辑抽离成一个函数，错误处理就是一件独立的事。
[b]9.do not repeat yourself
重复可能是软件中一切邪恶的根源。[/b]
整洁的代码并不是一开始就能写出来，就像文章的初稿一样可能混乱不堪，但经过[b]反复重构[/b]慢慢就形成了整洁的代码。这个重构不能隔太久，重构在平时。同时保证测试通过。重构和测试总是分不开的。
窃以为这本书第一章算是整洁之道，后面算是整洁之术吧。
[b]一、 代码整洁之道[/b]
代码永存，没有什么先进的代码工具能代替程序员。模糊的需求和精确的代码之间有个必须程序员才能弥补的鸿沟。
勒布朗法则：later equals never. 法则好简单，为什么做起来那么难呢？？有的[b]洁癖[/b]真的很吸引人。
花时间保持代码整洁不仅关系效率而且关系生存。破窗理论，破烂的代码是毁灭的第一步。
当老系统繁重的无法快速满足新变化时，重启新团队重新设计老系统，并与老系统并行运行的例子还是有一定的体会的，此事正好发生在我待过的项目。
写了不整洁的代码而因此承受惨重代价，这是程序员[b]自作自受[/b]，跟繁琐的需求，无止的变化，难以接受的进度，sx的经理都有关系，但还是要说，自作自受。
写混乱的代码就是最快的方式？ 不是，那是因为你根本写不出漂亮的代码。漂亮的代码才是最快的。你有[b]洁癖[/b]吗？艺术家的艺术。
[color=red][b]整洁的代码只做好一件事。尽可能的简单（如命令查询分离原则），尽可能的少依赖。[/b][/color]
简单的代码，依其重要顺序：
1. 能通过所有测试
2. [b]没有重复代码[/b]
3. 体现系统中的全部设计理念
4. 包括尽量少的实体，比如类，方法等。
消除重复和提高表达力（命名）能在代码整洁方面获益良多。
[b]不要重复代码，只做一件事，表达力，小规模抽象。概括了整洁代码的全部内容。[/b]
写新代码时我们一直在读旧代码。读写话费时间比例超过10：1。编写代码的难度，取决于读周边代码的难度。要想写的容易，先让代码易读吧。
美国童子军军规：让营地比你来时更干净。代码的每次check out, check in也是如此。
[b]二、 代码整洁之术[/b]
[b]2.1命名[/b]
[b]1.名副其实，见名知意。[/b]
1） 名字不要怕长，表达清楚更关键。
2） 魔鬼数字用有意义的常量
3） If里的条件能用一个有明确含义的功能方法表达更好。
到处需要命名
如：原始代码，
[img]http://dl2.iteye.com/upload/attachment/0088/9143/fc901943-cb3e-3404-a068-fd16396c0f10.bmp[/img]
重构后代码1：
[img]http://dl2.iteye.com/upload/attachment/0088/9145/1aade47b-c79b-3769-ba4d-f26de0b710bc.bmp[/img]
再次重构后2：
[img]http://dl2.iteye.com/upload/attachment/0088/9149/685d1ebd-4266-352e-b412-398cb419930e.bmp[/img]
[b]2.做有意义的区分[/b]
比如有两个类，ProductInfo, ProductData，名称虽然不同，但意义却无区别，就像a, an, the一样。这种情况在项目中也时常发生，至少我经历过。。。
[b]3.使用读得出来的名称[/b]
使用正确的[b]准确的英文[/b]表达。花些时间在命名上是非常值得的。不然，痛苦在后面...
单字母名称(如i,j)只应出现在短方法的本地变量。名称长度应与其作用域大小想对应。
若变量或常量多次出现在代码中，应赋予其便于搜索的名称。比如，
原始代码：
[img]http://dl2.iteye.com/upload/attachment/0088/9154/435513fb-8841-376c-8dc9-7ac56d03cfd3.bmp[/img]
重构后后:
[img]http://dl2.iteye.com/upload/attachment/0088/9156/e64a841a-bc6f-3e86-b6af-151f6d75f225.bmp[/img]
[b]4.类名[/b]
类名和对象名都应该是[b]名词或名词短语[/b]，如Customer, Account,AddressParser。类名不应该是动词。
[b]5.方法名[/b]
方法名应该是[b]动词或动词短语[/b]，如postPayment, save等。
[b]6.每个概念对应同一个词，一致的风格[/b]
每个类中采用一致的命名风格，如get***，set***，一词一意，以免概念模糊。可以采用通用的专业性的计算机术语，或问题领域的名称
[b]7.添加有意义的语境[/b]
比如添加前缀，lastName, firstName在表示的是地址的时候就可以用addrLastName,addrFirstName.但也不要添加无意义的前缀。
命名一定要精确。
[b]2.2 函数[/b]
[b]1.函数的第一规则是短小，第二规则是还要更短小。[/b]
If,else,while等代码块中的代码应该只有一行，大抵应该是一个函数调用，一个有较具说明性的名称的函数调用。当然有些极端，理念就是不做多余的事，做同一个抽象层次的事。
[b]2.只做一件事，做好一件事[/b]
做的事跟函数名称对应。一个函数做的事情越少，功能越集中，越好命名。
[b]3.每个函数一个抽象层级[/b]
函数中的每个语句，包括函数调用等应该是同一个抽象层次的。
[b]4.函数的参数[/b]
最理想的参数个数是零，其次是一，再次是二，应该避免三个。有些公司规范是不要超过5个。当参数个数要超过2个或3个时，就要看这些参数是否需要封装成类了。
[u]尽量使用返回值，不要使用输出参数。[/u]
[b]5.标识参数（boolean参数）[/b]
[img]http://dl2.iteye.com/upload/attachment/0088/9152/7ba4ac68-78e1-37d6-9d35-e84b675e5723.bmp[/img]
[b]6.使用异常代替错误返回码[/b]
我们要command-query分离，但有时候command会需要返回操作的结果，这时候可以用异常表示错误，否则表示正确，不需要再返回结果状态。
[b]7.分隔指令和查询（command-query分离）[/b]
[b]8.抽离try/catch块[/b]
Try/catch块搞乱了代码结构，可以把处理异常的逻辑抽离成一个函数，错误处理就是一件独立的事。
[b]9.do not repeat yourself
重复可能是软件中一切邪恶的根源。[/b]
整洁的代码并不是一开始就能写出来，就像文章的初稿一样可能混乱不堪，但经过[b]反复重构[/b]慢慢就形成了整洁的代码。这个重构不能隔太久，重构在平时。同时保证测试通过。重构和测试总是分不开的。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
