易读代码的艺术读后感摘抄

《易读代码的艺术》是一本由Dustin Boswell，Trevor Foucher著作，东南大学出版社出版的190图书，本书定价：39.00元，页数：2012-6，特精心收集的读后感，希望对大家能有帮助。

《易读代码的艺术》读后感(一)：对于写了一年代码的人比较适合

主要介绍了如何将代码写的更加易读。

1. 变量，函数，类等命名一定要能够根据名字就知道背后的含义

2. 易读的代码更加容易测试

3. 要学会将问题进行分解，分解成无关的问题，然后抽取到不同的地方。比如函数，类等

4. 写代码之前要试着将代码文件简单的文字进行描述，首先要自己用简单的语言能够写出来，然后再实现为code

5. 注释一定要精简

6. 对于变量不要在程序中到处修改，只修改一次的变量是最好的，因为我们更加容易知道变量的变化情况

7. 对于使用的语言库要了解常用的API，不要重复造轮子

总之，这些经验对于写好程序还是相当有价值的

《易读代码的艺术》读后感(二)：总结

好代码的标准：Code should be easy to understand.

可读性的基础：Code should be written to minimize the time it would take for someone else to understand it. （优化的标准）

以下所有的技巧都围绕一个原则：易读，易读，还是易读。

1.Pack information into your names

a.用词要精确 Choosing specific words DownloadPages和FetchPage 比GetPage好多了。

b.可以试着用一些富有想象力的词汇,但一定要简洁准确 Finding more "Colorful" words。

c.避免用一些普通的词 Avoid using generic names like tmp retval

The name "retval" doesn't pack infomation.Instead,use a name the describes the variable's value

The name "tmp" should be used only in cases when being short-lived and temporary is the most important fact about the value

loop iterator i,j,k 建议加上遍历对象标示 比如遍历用户 ui 遍历车 cj 遍历省份 pk

d.相比较抽象的名称，使用具体的名称更好一些 Prefer concrete names over abstract names

e.命名时尽量多附带一些额外的信息 Attaching extra information to a Name

f.Values with Units 给一些值带上单位 such as delay -> delay_secs ; size -> size_mb

g.Encoding Other Important Attributes 带上一些重要的属性 html —— html_utf8, data ——data_urlenc

h.命名的长度多长合适？ 标准：以新成员是否可以快速理解为基准。

i.Throwing out Unneeded words eg: ConvertToString() -ToString()

j.用命名规范传递一些信息 Use Name Formatting to convey Meaning 比如常量大写，私有变量以下划线结尾

2. Names that can't be misconstrued 名字不能有歧义

a.标准：总是带着“别人会不会被这个名字错误地理解到其他层面去”的想法来仔细地观察你的命名

b.Prefer min and max for (Inclusive) limits 类似边界值和限制条件的常量命名，尽量使用min/max, first/lasr,begin/end

c.Naming Booleans 布尔值或者返回值为布尔值的函数，命名一定要清晰地传递出true和false。 need_passwd比read_passwd好多了；HasSpaceLeft() 比SpaceLeft()更好一点。

d.MatchingExceptations of User 在很多时候，我们会用get*来命名一个获取成员变量的方法，假如有个占资源的方法以get开头，其他人可能不会意识到问题并去调用。//todo:

3. how to comment code

//todo:

1.control flow

a.所有conditionals,loops这些control flow应该尽可能的简单，written in a way that doesn't make the reader stop and reread your codes

b. when writing a comparison,it's better to put the changing value on the left and the more stable value on the right, eg: while (bytes_received < bytes_expected)

c. if/else statement ; Generally, try to handle the positive/easier/interesting case first.

d. returning early can remove nesting and clean up code in general

2.breaking down giant expressions

key : break down it into more digestible pieces

a. Explaining variables 最简单的方法简化一个长表达式就是使用额外的变量分割表达式并解释其含义

b.Summary Variables 有时候表达式过于分散，使用来很多变量, it takes a little extra time to think about.

eg:

if (request.userId == document.OwnerId ){ //todo }; if (request.userId != document.OwnerId ){ //todo };

more clearly的做法:

user_owns_document : = (request.userId == document.OwnerId) if user_owns_document { //todo } if !user_owns_document { //todo }

3.Using De Morgan's law 摩根定律简化简化逻辑条件判断 if(!(xxx && !yyy)){ //todo } ==> if ( !xxx || yyy )

4.Abusing short-circuit logic 不要为了简化代码，写让人费解的short-circuit logic，简洁性前提是易读性，尽量不让别人读你代码的时候打奔儿

《易读代码的艺术》读后感(三)：《The Art of Readable Code》 读书笔记

《The Art of Readable Code》是一本关于代码可读性的书，很薄，180页，我手中的版本是2012年6月由东南大学出版社出版的影印版，其英文原版则是2011年出版的，已经是一本7年前的书了。一般而言，IT技术的发展之快导致技术书籍中提到的技术很快就会过期，但是这本不同，书中的观点和知识至今仍对我的工作学习提供了不小的帮助，以至于我想通过一篇读书笔记来记录、整理书中的要点，便于以后时时翻阅、时时温习。

本书分为4大部分，15章，各章又细分为多个要点。本书的主旨可以归结为之前在网上看到的一句话：代码的目的是给人阅读的,只是顺便能让机器运行而已。进而言之，是如何提高代码的可读性。书中的四大部分从易到难、由浅至深地介绍了提高代码可读性的方法，以下则是我对该书主要内容的摘录和理解。

在前言中，作者首先提出，通过对大量“bad code”的分析，他发现坏代码和好代码的区别就在于代码的可读性，进而，他提出了一个写可读性代码的原则：

这一原则不仅适用于多人项目，同时也适用于个人项目，毕竟那个”someone else“可能就是六个月之后的你。

这一章举了一些例子用于说明一些命名的模糊性和易于产生误解的地方。一般而言，我们在代码中，应该选择一个单词最常见、常用的含义，避免那些生僻的含义，在命名时要多想一想，这个命名会不会让别人误以为是别的什么意思，有没有更合适、更专指的命名可以用在这个地方。

这一章主要讲代码的格式化问题，我想大多数程序员在写过一两年代码之后都会意识到这个问题的重要性。毕竟读、维护没有良好格式化的代码实在是一件十分头疼的事情。除了空格、缩紧之外，这一章来提到可以通过列对齐来保证可读性，可以通过将长代码分段、分块并注释来解决大量的变量初始化导致的大坨代码，最后，作者提出，团队约定优先于个人喜好，这算是对缩紧、大括号换行等经典争论的一个解决吧。当然，团队没有约定的话，那就先吵一架把它约定好吧。

首先，能通过代码表达的就不要用注释表达，信息冗余也会降低可读性

其次，注释应该记录你的想法，提供你认为读懂这段代码所需要的额外信息，此外关于为什么选择一种方案而不是另一种方案、代码未来可以优化的地方以及代码中的常量的设置，都值得写上注释。

然后，站在读者的角度，想象一下一个新来的同事看到你的代码会怎么想，会有怎样的困惑，这样你就知道要怎么写了。尤其是在方法和文件的开头，写一些总结性的注释，以免读者被一些细节纠结而丧失了对代码整体的理解。

最后，不要怕写注释，不要怕语言组织不好，先写出来比较重要，不一定书面，口语也是可以的。

控制流程主要是各种条件/循环语句，在代码中不可避免地会写一些条件/循环语句，本质上讲，这些语句都是对原有的自上而下运行的代码执行顺序的破坏。因此如果不注意的话，常常会导致代码的可读性变差。因此作者在这一章提出了一些建议以提高这种代码的可读性。

大块的代码就像一坨shit，远远望过去堆得密密麻麻，让人只想敬而远之。改善这种shit代码的方法的一个有效途径是用命名合理清晰的变量代替一些表达式，将一些条件判断改写成更合理有效的表达式，

作者在这一章主要的意思是，变量越多，在阅读代码时需要记住、追踪的就越多；变量所处的作用域越大，需要记住这一变量的时间就越长；变量在代码运行过程中变化的地方越多，就需要你更频繁地去更新变量的状态。而这些都是对阅读者的脑力的考验，因此需要尽量去避免这些情况。

##重新组织你的代码

作者在这一章的建议是，主动地去识别并抽取不相关的子问题。可以先对某一方法或者某一代码块的主要目标/根本目的做总结，然后看是不是有一些代码并不是直接服务于这一主要目标，如果存在的话，看一下是不是可以将这些代码抽出。久而久之就可以形成一些一般性的、通用的工具方法，可以在整个项目甚至整个团队中通用。当然，即使不是通用的而是强业务相关的方法，也是可以抽取出来的，只要能提高代码的可读性就是没问题的。

这一章其实与第10章的内容有些类似，但是从不同的角度来阐述而又有扩展。一次只处理一个任务是指把大的任务分成多个小任务来完成，每次只处理其中一个。这一建议不仅适用于方法的拆分，也适用于大块的代码，可以将大块的代码拆成多个小代码块。如果代码中遇到了这种可读性很差的大代码块可以试试这种方法，分析其中有多少小任务，尝试把这些小任务清晰地分离开来。

有的时候一段复杂的逻辑会导致代码混乱难懂，其中又混杂着各种细节和hack，代码就会变得更加混乱难以理解。这时候可以用作者在这一章中提出的方法，这一方法其实有点像著名的小黄鸭调试法(Rubber Duck Debugging)。先用自然语言描述一下你这段代码要完成的任务，然后抽取其中的关键词，写成代码。

这一章主要是讲保持测试代码的可读性，说实话，我平时代码中用到的测试不多，毕竟前端设计到的大量UI层面很难去测试。作者在这一章提出的主要建议是：

这一章的主要内容是一个案例，在代码中应用了前面所说的主要方法，写出可读性高的代码。此处略去不表。

略

以上就是《The Art of Readable Code》一书的主要内容，读完此书之后，我认为其中的大量观点和建议都很有参考价值，对于提高我们的代码质量很有帮助。当然其中一些方法和建议不是很容易在实际工作中应用，但是我觉得至少我们在写代码时应该始终存着一个念头：我这种写法会不会让其他人看不懂、这一段代码是不是很难理解。只要心中有这个想法，那我们就自然会着手想方设法提高我们代码的可读性，这时，书中的建议和方法就体现了他们的价值，会被我们运用到代码中去。

##后记

这是我个人读完的第一本英文技术书，谨以此文纪念。