《The Art of Readable Code》是一本关于编写易读代码的书籍。作者分享了许多实用的技巧和方法，帮助程序员提高代码的可读性和可维护性。通过简洁清晰的代码，可以让团队更高效地合作，减少错误和提升代码质量。这本书对于任何想要提升编程技能的人都是一本不可多得的好书。
The Art of Readable Code读后感(一)
本书讲的都是很容易被忽视，但如果做到了对代码可读性会有很大的提高的实践经验。非常认同其中关于测试代码编写的实践经验，与之前我们项目中编写的一些测试代码的思想是一致的。建议不管什么水平的码农都可以翻翻，总有有些收获的。
The Art of Readable Code读后感(二)
这本书很有特点，配的漫画很幽默。
三个方面是，变量名，表达式和控制结构，最后是整体结构，包括分层和算法的可读性等。
希望能看到中文版。
还需要多少字啊？
请尊重创作者的劳动，勿提供下载信息、或转载他人的文章。
为了鼓励有益的分享, 少于50字的评论将在前页论坛里发表。
The Art of Readable Code读后感(三)
俗话说“函数应该只做一件事” ，没错，分解大函数为小函数是好的。但是，它并不一定是函数的界限。如果你愿意的话，仍然可以组织你的大代码感觉像有独立的分段组成的。举的例子很贴切！
Turning Thoughts into Code
还不能够清楚理解要解决的问题时候，不要下手写代码。写的代码要能够简明的解决问题，而不是在自己绕圈。
The Art of Readable Code读后感(四)
每次碰到一本好书，总会觉得相见恨晚，无疑《The Art of Readable Code》是编写程序之路上越早看到越好的一本书。大神Donald E. Knuth曾经说过：“Instead of imagining that our main tasks is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do“ 编写程序不仅是去告诉计算机你要做什么，更重要的是让人明白，你想要让计算机去做什么。 而编写简洁、清晰、美观、容易理解的代码，才能够让”人“容易明白自己的意图。
简约，清晰，容易让人理解的代码，大部分时间都远比那些看起来很酷的代码更高效，更容易维护；更别提比那些七拼八凑来的仅仅是为了完成任务的代码了（这样的代码，就是谋杀——因为要花费别人大量的时间理解、改问题、维护、或者完全重写——而且，丑陋的代码会让看代码的人抓狂，心情变差——这些都是在谋杀令一个生命）。
其实，大部分的码农，都是想要做一个好的程序员的吧——就像大部分的人想要过幸福的生活一样吧——然而很多事情并不是我们希望就能够变成想要的那个样子——很多时候，我们只是不知道该要怎么去做（而且还不去想），我们只是缺乏编写好代码的技能，如同我们缺乏把日子过的幸福的技能一样。而这么一本书，就是告诉我们，有很多简单的技巧，可以让代码的质量提升很多，就如同生活中，开始培养几个简单的习惯，就能够让生活大为改观一样。
The Art of Readable Code读后感(五)
看看书里面的小节标题就可以了，
书的内容都浓缩在标题里面了。
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
抱歉，你的评论太短了
The Art of Readable Code读后感(六)
var update_highlight = function (message_num) {
var thumbs_up = $("#thumbs_up" + message_num);
var thumbs_down = $("#thumbs_down" + message_num);
var vote_value = $("#vote_value" + message_num).html();
var hi = "highlighted";
vote_value === "Up" ？ thumbs_up.addClass(hi)
: thumbs_up.removeClass(hi);
vote_value === "Down" ？ thumbs_down.addClass(hi)
: thumbs_down.removeClass(hi);
};
The Art of Readable Code读后感(七)
接着去年11月份实习时用 kindle 读到 20% 落下的好书，中间隔了几个月...
这本新书的名字也是“The Art of xxx”，很容易让我感觉到这是很严谨不易读的书，那本 TAOCP 是我这种数学能力超弱的人读不了的，而 TAOUP 对几乎没怎么用过 Unix/Linux 的我也比较难理解甚至不知所云。但是这本 Readable Code 却明显不像我先入为主的感觉那般，而是跟其书中让 code 更 readable 一样易读。
这本书容易读是因为作者几乎不用隐喻（Metaphor），也没有那些 DRY 原则（我看全书只是一笔带过一次而已）之类的缩写“术语”，而是用直白浅显的文字表达出来，简单明了。如果这些很适合新手阅读并注意的主题，隐喻过多显然达不到最主要的目的，但本书避免了这种问题，这是本书做得很好的一点。
另外，书中每一章至少有一幅跟主题相关的幽默漫画，在诙谐的同时引起你继续读下去的兴趣，还可能让你更能记住书中提到的那些“KEY IDEA”或具有指导/总结性质的章节名。英文单词也够简单，用 kindle 查一下足够了。
书中不仅用很多代码片段来说明问题，在最后第四部分的“Selected Topics”用比较完整的例子渐进式地讲了“Testing and Readability”和实现一个作者实际的产品代码“minute/hour counter”，后者涉及代码性能和内存消耗，看看作者怎么把整本书的主要方法运用到实践当中去。
我读过的与这本书类似的有《代码大全2》（大部头，面面俱到）和《重构》（这本 Refactoring 也比较好读，不过感觉偏向于“设计”，甚至是设计模式，性能、注释这些印象中没提到）。作者在最后推荐的阅读的书单中也包含了这两本，还有其他经典书。
几处自己觉得有趣的地方：
- 三目条件运算符 ？: 只能用于最简单的情况跟《代码大全 第二版》（Code Complete）一样提倡函数中尽早返回（return），但这里提到其他需要单退出点（single exit point）的情况（例如一些清理工作），已经被析构函数和 try finally 或 Python 的 with、C# 的 using 取代了。
- 别轻易一票否决臭名昭著的 goto，需要仔细研究它，有时候还是有用的，例如 Linux 内核就用到了。
- 代码里多重嵌套时，读代码的人不简单啊，因为要构造一个“mental stack”，然后看到 } 要记得按序“pop”出“mental stack”。觉得这个新词“mental stack”很有意思。
以作者一句话来结束：“Our book is intended to be a fun, casual read.”
p.s. 现在才知道“a.k.a.”是“also known as”的缩写，少读英文资料的悲剧啊，是程序员的从这本易读有用的书开始读原版书，一点点攒起来吧。
The Art of Readable Code读后感(八)
《The art of readable code》笔记 25 November 2012 前言 入职新公司，接收前任留下的code，觉得有些凌乱，于是乘势带着学习的心态又把整个代码重写了遍。期间又把去年读过的这本书拿过来重读了一遍，这本书举的例子是作者平时的一些总结，作为顶尖互联网公司(Google)的工程师对自己的一些“反省”，我觉得还是有普遍性的，很值得学习。 写代码的原则 Code应该让别人花尽可能短的时间看懂/理解。 不由得想起这句名言 Programs must be written for people to read, and only incidentally for machines to execute. Abelson & Sussman, SICP, preface to the first edition 所以写代码的同时应该具有一种对可能看你代码的人的一种同情心，推己及人，站在阅读者的角度考虑一下，也许多思考一下加些该加的注释，或许会让看你代码的人少些痛苦，如果能多些愉悦，那就谢天谢地了。 作者还提到一句比较本质的话摘录在这里： Engineering is all about breaking down big problems into smaller ones and putting the solutions for those problems back together author of this book 该书有小到大展开，各章节如下： 变量名 Joshua Bloch在设计Java API时，身边总会放一本字典，（《Coders at works》p172）可见其对名字的重视程度。作为可读性的基石，变量名直接决定了代码质量的好坏。总结了一些： i/j/k不应该在循环变量之外出现这样的变量名。而且嵌套循环时还要考虑尽量不要用这样的变量名，因为如果取错index的话很难debug出来，而带有意义的index则一样就能看出来取错index了。 temp/tmp/ret 仅用在显而易见的短的范围内，作为函数的返回值或者临时变量，除此之外杜绝使用。 将变量附带一些信息： 附带类型： 如_str, _arr， _p等 如果是测量性质的最好带上单位： max_file_size_mb 约束性质的最好带上边界词： max_xxx, min_xxx 半开半闭区间的边界值变量：begin, end 闭区间的边界值变量： first, last 布尔变量带上： is, has, can, should让人一眼明了 定义的位置： 不要先定义一大坨变量放在那里，用到的时候再定义也不迟。 代码风格 参见kernel style 注释原则 好代码 > 烂代码 + 好注释 所以优先考虑写好代码然后再考虑写好注释的事。 用TODO（要干的）/FIXME(已知不完美的)/HACK(承认写的挫的） 传参时有需要可以加inline注释 log_new_file(file_name, /* max_file_count= */10, /*max_file_size_mb=*/10) 这样别人就不用再去看API找这两个参数什么意思了 control flow方面 不要使用 do while （宏里面除外） if/else处理先后原则： 先处理positive 先处理简单 先处理最interesting的 将大的表达式简化 考虑用一个“cache”变量缓存大的表达式 考虑用宏替换一些重复的代码 less code 又一句牛逼的话： The most readable code is no code at all 映衬了这句话： Less is more 建筑大师：路德維希·密斯·凡德羅 所以： 不要舍不得代码，觉得辛辛苦苦写的，该丢的丢，该删的删。要大气 尽量多些通用的utility代码库，然后删除重复的部分 将项目划分为正交的子项目 对codebase的大小心里要有数 没事看看你用的语言的API，找找感觉，下次有什么需求时就会想到有API而不是在那重复造轮子了。
