代码整洁之道1-6章总结

第一章 整洁代码

总的来说就是，整洁的代码有益于团队的测试开发，往大了说会影响公司的发展。作者列举了几个公司的反面教材，由于代码不够整洁，无法继续维护，导致公司倒闭的情况（迭代周期越来越长），所以说作为一个程序员，都有义务和责任去尽量写出简洁优美的代码！

本书的作者是总结了多位大咖几十年来的开发经验，这很难得，但同时他也指出，并非所有人都同意这些简洁之道，甚至强烈反对其中的一些建议，但我们最终还是要吸收其精华，无论是否真的运用到代码当中。

其中，作者做个了一个有趣的调查就是，通常我们认为自己写代码的时间很长，而其实我们写代码和读之前的代码的时间比例是1:10，这也要求了我们要写出整洁的代码，以便我们更快的完成需求。

 

第二章 有意义的命名

这一章是对各种命名规则的一个建议，其中我总结出了几个最常用也是最重要的几条原则：

1、名副其实

指的是我们的名字要尽量贴合其要代表的意思，而非仅仅list、array这样简单的名称，每当发现有更好的名字可以替换之前的名字时候，可以毫不犹豫的去替换，因为现在的编译器和帮助你顺利完成，而这可以帮助你更好的体会变量的含义。

2、做有意义的区分

主要指不要在相似的命名中做无意义的区分，可以增大区分的程度，例如我就总爱用name1、name2。。。等等来命名不同的名字，而这是不正确的，要明确每个名字的含义来命名，其实也属于第一条的范畴。

 

3、使用领域相关的名称

大家都是程序员，没必要为了别人通俗易懂来命名，完全可以用专业术语来命名。

 

4、使用可搜索的名称

作者认为单字母名称仅用于短方法中的本地变量。而名称的长短与其作用域大小相对应，也就说不要怕取长名字，只要符合上面的要求，那么就是好名字。同时作者指出，好的整洁代码就如同读文章一样，看到名字就知道在干什么。这也与后面的注释那一章遥相呼应。

5、使用描述性的名称

这是第三章写函数名称的，但我将它归类到这。其实也适用于参数、变量等命名。其目的和第四条相似，让读者见其名知其意。

 

第三章 函数

 

1、短小

函数一定要小，然后要更小（一个函数的最多不要超过20行！）。这点深有体会，因为刚入职学习现有的项目，发现越短小的函数越容易理解（即使多次跳转），反而那些长达几百行的函数看着就没有食欲！！！！尤其是if..else嵌套语句，如果超过三层就会让人头晕，没有看下去的欲望。这一点作者也做个严格的限制就是，这些嵌套语句不应该多于一层（个人感觉太严格了，2层嵌套还是有必要的）并且嵌套也不该有长篇大论（这一点我觉得也好严苛啊！！！），这些嵌套里面通常只是一个函数的调用。

 

2、只做一件事

这一点很好理解，就是一个函数不应该完成许多事情，这个和命名规则相互联系，就是（一件事+一个名副其实的名字）来完成一个短小的函数。判断函数是否只做了一件事，看在函数中能否再提炼出一个新的函数，该函数不仅仅是单纯地重新诠释其实现。每一个函数都完成一个抽象层级，就是代表着在完成一件事（自己体会）。。。。

3、消灭重复代码

我经常犯的错误，将短小而重复代码直接复制粘贴。虽然现在一时爽，维护的时候就是火葬场，因为不知不觉就会不断扩大复制的代码，而把原有的结构变得臃肿复杂。所以即使在短小的重复代码也要消灭掉。

4、无副作用

其实这一点很难，说直白点就是不要函数有耦合，这个在整个规划时候就要规划后，如果没有规划后期很难避免。

5、使用异常代替返回错误码

这条不用多说了，正常开发没有用错误代码的了吧。注意一点就是将try/catch块也要抽离出来，避免函数过长，同时异常处理函数也要满足上面的规则，只完成一件事。

6、参数要少

这一点作者要求的也很严格，竟然把三个形参作为最多的情况。不过的确参数越多，越难理解函数的意图（我接手的代码竟然有10几个参数的函数，简直崩溃）

 

第四章 注释

这一章其实我挺不赞同，的确好的注释是越少越好，但只限于好的代码前提下。对于新手以及没有好的习惯的程序员来说，我觉得注释是帮助自己完善代码的好方式（尤其是代码没完成时候，注释可以帮助自己记录自己的思路）

我刚入职的时候，接手的项目注释就非常少，而代码又不是如作者那样写的整洁（虽然开发人员已经认为整洁了，但仍然有好几层的嵌套和重复逻辑，甚至200多行的函数）。所以对于这样的项目，注释多点感觉不为过，相反没有注释又没有整洁的代码，简直就是灾难，完全靠猜。

一、注释要少

要用代码阐述，而不是注释。

二、坏注释

注释不需要喃喃自语（就是自己写给自己的话），和无意义的注释（一眼看出来的语句就不要注释）。同时作者不赞同在函数头前增加函数说明和参数说明，我觉得是有异议的，这一点是在满足前面命名规则和函数规则的条件下，才可实现，如果一个函数名称起的不好，而参数又非常多，那么函数的函数头注释就非常有必要。

三、好注释

作者认为，注释只有少数情况才会被添加，包括法律信息、提供信息的注释、不好理解的算法、警告、TODO注释（将来要修改或添加的提示）。如果按照这些写注释，那么注释真的会很少！

 

第五章 格式

这一章写过代码基本都有体会了，横向竖向都有一定的缩进和留白（是不是和国画很像呢！），而且现代编辑器也会帮助你完成许多工作。作者指出，每一行的代码不要超出屏幕，就是不要拖动横向的滚动条来看代码，同时要缩短每行的代码。