如何编写简洁的代码？

引言

学习来源：《Clean Code》 [美] Robert C.Martin。

这是本人的学习笔记，如今大部分写代码的时候已经对这些规则和概念有了一个清晰的认识，但愿你们有机会也能看一看《Clean Code》这本书，总结出属于本身须要的规则。

一.有意义的命名

1.名副其实

int d;//消逝的时间,以日计
int elapsedTimeInDays;
复制代码

2.避免误导

别用accountList来指称一组帐号，除非它真的是List类型。提防使用不一样之处较小的名称。误导性名称最可怕的例子，是用小写字母“l”和大写字母“O”做为变量名。由于他们看起来实在太像数字“零”和“壹”。如如下代码：

int a=l;
if(O==l)
  a=O1;
else
 l=01;复制代码

3.作有意义的区分

废话是另外一种没意义的区分。例如你有一个Product类和一个ProductInfo类,这两个名称虽然不一样,意思却毫无区别。

4.使用读的出来的名称

像生成时间戳 这个变量应该是 generationTimestamp 而不是 genymdhms . 

5.使用可搜索的名称

尽可能避免使用单字母和数字做为常量名称，由于它们一般很难在一大段代码中被准确的搜索出来。做者认为 单字母名称 仅用于短方法中的本地变量。名称长短应与其做用域大小相对应。

6.避免使用编码

把类型和做用域编进名称里面，徒然增长了解码的负担。典型的如：

1. 匈牙利语标记法
2. 成员前缀（不必使用前缀来标明成员变量，应当把类和函数作的足够小，消除对成员前缀的须要）以下代码：

public class Part{
  String description;
  void setDescription(String description){
    this.description=description;
  }
}复制代码

7.避免思惟映射

不要让读者在脑中把你的名称翻译为他们熟知的名称。这种问题常常出如今选择是使用问题领域术语仍是解决方案术语时。

8.类名

类名应该是名词或名词短语，例如 Customer、WikiPage、Account 和 AddressParser，避免使用 Manager、Processor、Data或者Info这样的类名。

类名不该当是动词。

9.方法名

方法名应当是动词或动词短语，如 postPayment、deletePage 或save。

10.每一个概念对应一个词

给每一个抽象概念选一个词，而且一以贯之。例如，使用fetch、retrieve和 get 来给在多个类中的同种方法命名。

11.使用解决方案领域名称

记住，只有程序员才会读你的代码。因此，尽管使用那些计算机科学术语、算法名、模式名、数学术语吧。依据问题所涉领域来命名可不算是聪明的作法。

12.使用源自所涉问题领域的名称

若是不能使用解决方案领域名称来命名，就采用所涉问题领域的名称，至少负责维护代码的程序员能够去请教该领域专家。

13.添加有意义的语境

让你的代码读起来是连贯的，是在同一语境的。能明确的知道，这些类，函数是某个结构的一部分。这须要经过良好命名的类，函数和命名空间来造成有意义的语境。

14.不要添加没用的语境

只要短名称足够清楚，就比长名称好，不要一昧的追求长名称，从而形成不少没必要要的语境。给人以困扰。

二.函数

1.第一规则：短小

if语句、else语句、while语句等，其中的代码块应该只有一行。函数的缩进层级不该该多于一层或两层。

2.只作一件事

函数应该只作一件事，作好这一件事。

3.每一个函数一个抽象层级

自顶向下读代码：向下原则。

4.使用描述性的名称

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

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

5.函数参数

参数数量尽量的少，最好的是零参数函数，其次是一（单参数函数），再次是二（双参数函数），应尽可能避免三（三参数函数）。

5.1 标识参数

应当尽可能避免标识参数，避免向函数传入布尔值。

5.2 三元函数

写三元函数以前必定要深思熟虑，是否有必须写三个参数的必要性。

5.3 参数对象

若是函数须要两个，三个或三个以上的参数，就说明其中一些参数应该封装为类了。

5.4 动词与关键字

对于一元函数，函数和参数应当造成一种很是良好的动词/名词对形式。

例如：write(name),或者更好的名称：writeField(name)。
例如：assertEqual改为assertExpectedEqualsActual(expected,actual)。
复制代码

5.5 错误处理

• 使用异常代替返回错误码
• 抽离Try / Catch 代码块
• 函数应该只作一件事，错误处理就是一件事。所以，错误处理的函数不应作其余事。

5.6 别重复本身

不要编写重复性的函数。

5.7 结构化编程

Edsger Dijkstra的结构化编程规则。

三.注释

关于注释的问题，首先咱们应该明确的是能用代码阐述的就不要写注释，避免误导。也就是代码可读性很是高，几乎能够不用注释，这须要良好的命名习惯来造成。另外，注释并不可以美化你写的糟糕的代码。与其有时间写注释，不如花时间优化你的代码。若是咱们在必须写注释的状况下，须要明确的知道本身想要写的是好注释仍是坏注释。

好注释

法律信息（例如版权及著做声明）

提供信息的注释（例如解释某个抽象方法的返回值，固然更好的是在方法名中体现，从而省略注释）

对意图的解释（对某些看起来与常理不符合的代码解释你的意图，如 sleep 函数）

警示（警告执行后会出现某些后果的代码）

TODO 注释（告诉其余人这里还有个未完成的工做，以及未来完成后应该是怎么样的）

坏注释

多余的注释

日志式注释（记录每次的修改日志，目前在源代码管理很是完善的今天，日志式注释应该被废弃了）

注释掉的代码（不要直接注释掉代码！无用则请删除，注释而不是删除会让其余人误觉得这段代码仍有用处）

归属与署名（经过源代码管理，署名也是能够被废弃的）

括号后面的注释（不要在括号后面写注释）

信息过多（别在注释中添加可有可无的信息）

PDF资源

这里是书籍的PDF版本（中英文版本均有），从网上搜集而来。

百度云：连接: https://pan.baidu.com/s/1FRjifuXzEeJcayDUtDmCXA 提取码: h3rs 

不过仍是但愿你们能尽可能支持正版哈，纸质书看起来比较有感受~。