Clean Code读后感一

最近由于一系列原因正在艰苦的啃书中（主要原因还是在面试的时候被教育了，确实发现自己没有阅读的习惯，这个习惯正在准备慢慢养成中），先感觉还是了解一下代码的各种规范再说。

        首先只能说这本书真的是惊到我了，我感觉之前工作中的代码被批得体无完肤，真是惨，具体的细节和震惊到我的部分我会在下面详细的列出来。

开篇的文章就对我来说很有共鸣感，之前的工作中也出现过这种的情况，之前的工作中有些需求因为一直改动和工期的问题，我们就直接追求最后的结果，并没有对于代码的种种的冗余性能之类的给予优化，因为每次都是想说这个需求改动的太多了，我们先发上去之后我们再改。Clean Code开篇就提出了一个概念Later equals never，我感觉真是这么回事，事实上之前工作中最后不合理的代码只要没有出现生产问题的事实上最后都没有改动过.......

   制造混乱无助于赶上期限，赶上期限唯一的方法——就是始终尽可能保持代码整洁

          第一章我们就简单的有共鸣就跳过了，我们来总结下各个其他章节作者想教我们学会的事吧。

 第二章有意义的命名

名副其实——最好要腾出时间来考虑属性或方法的命名，而不是随便给属性和方法取一个没有具体意义的名称。

避免误导——使用明确的区分度较大的命名，避免用会引起误解的譬如O、l这种命名法

做有意义的区分——尽量使用明确的描述内容的名称来定义类和属性，避免类似info、data、Object此类的命名方式

使用读的出来的命名方式——不要使用缩写在代码中进行命名

使用可搜索的名称——使用静态常量代替代码中的常量

避免思维映射——不要用自己的思维映射方式来揣测其他人对于命名的理解

类名——类是用来描述一种具体事物的，不应当是一个动词

方法名——方法是用来描述某一事物的某一动作的，应当是动词或者是动词短语

别扮可爱——不要使用俚语来进行命名

每个概念一个词——使用同样的概念，譬如getXXX

别用双关语——在同种类型的操作中采用同样的方法名，如果操作有所不同或者是实现或者是原理有所不同，请使用不同的方法重新命名

使用计算机术语进行命名或者是问题领域的名称进行命名，这样能够使得下一个读代码的人能够清楚的知道代码的意义。

添加语境——可以在局部地点添加属性和方法的语境，使用譬如JYXXX进行命名，但是请控制范围，如果这个部分没法造成区分，请不要添加。

第三章函数

   函数这章核心想告诉我们的就是——一个方法做且只做一件事，并且短小到不能再抽取方法为止。

只在一个抽象层级——注意函数在抽象层级上面占据的位置不要跃层。

Switch——使用工厂和接口的模式来掩盖switch函数

使用描述性的名称——使用有意义的函数名称，并且尽量的明确

函数参数——输入的参数尽量少

一元函数的普遍形式——如果函数要对输入参数进行转换操作，转换结果就该体现为返回值。不要使用boolean作为输入参数。

二元函数——尽量避免，除非是单个值的有序组成部分，类似new Point(0,0)

三元函数——尽量避免，免不了可以使用新的类进行封装

动词与关键字——函数名字应体现函数动作和参数的关系，譬如writeField(name)

无副作用——注意函数只做一件事，尽量避免做除了函数名能描述之外的其他任何操作。

输出参数——不要将输入参数当作输出参数来用

分隔指令和询问——避免出现这种情况，一个函数动作如果成功返回A，失败返回B，然后进行判断，我们可以通过try/catch进行处理。

使用异常替代返回错误——充分利用java的错误处理机制来进行编程

抽离try/catch——try/catch中的每一块内容应该就是一个独立的事（函数）

别重复自己——使用面向对象的方法将代码集中到基类避免冗余

结构化编程——如果函数足够短，出现return，break,continue并没有什么错

怎么做——我们不可能一次性就把代码写成这样，所以我们可以慢慢的通过不断的重构来慢慢优化我们的代码结构。

第四章注释

   这一章的重点就是——需要注释本身就是一种失败，真正可读性非常好的代码不需要注释，但是由于一般的局限性我们还是需要注释，那我们尽量把注释写的好些。

          不要太过相信注释，代码才是对于客观现实最直观的解释。

好的注释——对于意图的解释，对于晦涩的代码的阐释，对于关键内容的警告，TODO改写没有写的代码

坏注释——由于SVN等代码版本控制的出现，循规式的注释、日志式注释、归属于署名

    注释掉的代码、废话、喃喃自语、误导性的注释等废话，发现我之前的注释大部分属于这一种把，想想也真是个灾难，由于之前的工作中代码函数的不规范性，所以我当时在注释方面还特别的给予了提示，按照书中的说法，大概都是废话吧。