第一章整洁代码

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

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

其中，作者做个了一个有趣的调查就是，通常我们认为自己写代码的时间很长，而其实我们写代码和读之前的代码的时间比例是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注释（将来要修改或添加的提示）。如果按照这些写注释，那么注释真的会很少！

第五章格式

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

代码整洁之道1-6章总结相关推荐

《代码整洁之道》第一章整洁代码 ---为什么需要整洁代码？
第一章整洁代码概述什么是整洁代码? 开始走向整洁代码概述欢迎阅读本栏目的读者,如果你想成为更加优秀的coder,请跟随笔者的观点去解析<代码整洁之道>这本书,相信你会收获颇丰. ...
Clean Code 《代码整洁之道》前四章读书笔记
第一章: 整洁的代码只做好一件事减少重复代码提高表达力提早构建简单抽象让营地比你来时更干净第二章:有意义的命名名副其实:如果名称需要注释来补充,就不算是名副其实. 一定要注意命名,一旦发现 ...
读《代码整洁之道》前四章浅显印象和我所见的不整洁代码引以为戒
1.根本----良好端正的态度. 2.命名----有意义,规范,可搜索的名称,使用源自问题领域的名称,至少避免误导. 3.类名----名词或者名词短语. 4.方法----应当是动词或者动词短语. 5. ...
《代码整洁之道》—第1章1.1节要有代码
本节书摘来自异步社区<代码整洁之道>一书中的第1章1.1节要有代码,作者[美]Robert C. Martin,更多章节内容可以访问云栖社区"异步社区"公众号查看. 第 ...
【苦练基本功】代码整洁之道 pt1（第1章-第3章）
代码整洁之道 pt1(第1章-第3章) 1 整洁代码 1.1 要有代码 1.2 糟糕的代码 1.3 混乱的代价 1.3.1 什么是整洁代码? 2 有意义的命名 2.1 名副其实 2.2 避免误导 2. ...
【苦练基本功】代码整洁之道 pt4（第10章-第12章）
代码整洁之道 pt4(第10章-第12章) 10 类 10.1 类的组织 10.2 类应该短小 10.2.1 单一权责原则 10.2.2 内聚 10.2.3 保持内聚性就会得到许多短小的类 10.3 ...
【苦练基本功】代码整洁之道 pt3（第7章-第9章）
代码整洁之道 pt3(第7章-第9章) 7 错误处理 7.1 使用异常而非返回码 7.2 先写try-catch-finally 7.3 使用未检异常 7.4 给出异常发生的环境说明 7.5 依调用者 ...
【苦练基本功】代码整洁之道 pt2（第4章-第6章）
代码整洁之道 pt2(第4章-第6章) 4 注释 4.1 注释不能美化糟糕的代码 4.2 用代码来阐述 4.3 好注释 4.3.1 法律信息 4.3.2 提供信息的注释 4.3.3 对意图的解释 4. ...
《代码整洁之道》—第1章1.4节思想流派
本节书摘来自异步社区<代码整洁之道>一书中的第1章1.4节思想流派,作者[美]Robert C. Martin,更多章节内容可以访问云栖社区"异步社区"公众号查看. 1 ...
代码整洁之道精华——第十四章逐步改进
阅读本文有两种原因:第一,你是个程序员:第二,你想成为更好的程序员.你如果想成为更好的程序员,那就请细细品味文章内容,它绝不会让你失望. 代码整洁之道教给大家如何编写整洁的代码,而不仅仅是能运行的代码 ...

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

第一章整洁代码

第二章有意义的命名

1、名副其实

2、做有意义的区分

3、使用领域相关的名称

4、使用可搜索的名称

5、使用描述性的名称

第三章函数

1、短小

2、只做一件事

3、消灭重复代码

4、无副作用

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

6、参数要少

第四章注释

一、注释要少

二、坏注释

三、好注释

第五章格式

代码整洁之道1-6章总结相关推荐

最新文章

热门文章

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

第一章 整洁代码

第二章 有意义的命名

1、名副其实

2、做有意义的区分

3、使用领域相关的名称

4、使用可搜索的名称

5、使用描述性的名称

第三章 函数

1、短小

2、只做一件事

3、消灭重复代码

4、无副作用

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

6、参数要少

第四章 注释

一、注释要少

二、坏注释

三、好注释

第五章 格式

代码整洁之道1-6章总结相关推荐

最新文章

热门文章

第一章整洁代码

第二章有意义的命名

第三章函数

第四章注释

第五章格式