Here is the article.
Head First 系列书有一个特殊的章节：“there are no dump questions"。这个章节给我的启发是：没想透一些看起来很“傻”问题，你对问题所针对的事物的理解就还不够透彻（比如，苹果为什么会掉下来）。《The Art of Readable Code》这本书中，列了很多问题，看起来像是“傻问题”，并详细分析，从而让我们对什么是“可读”有了更深的理解。本文摘出书中最重要的 关键思想 及一些解读，从而让已全面翻阅此书的同学能快速想到相关内容。
可读性的基本定理
代码的写法应当使别人理解它所需的时间最小化。
表面层次优化
审美与设计
一致的风格比“正确”的风格更重要
该写什么注释
注释的目的是尽量帮助读者了解得和作者一样多
写出言简意赅的注释
注释应当有很高的 信息/空间 率
以上为表面层次优化部分的 关键思想 。由关键思想为原则出发，可以指导我们做出具体决策，简言之，代码也需要信达雅。高效地传达所有必需的信息给代码阅读者。高效 需考虑代码和注释的段落美观一致，言辞的精简准确，且不冗余（常见的冗余是注释与代码重复表达同一信息）
简化循环和逻辑
让控制流变得易读
把条件，循环以及其他对控制流的改变做得越“自然”越好，运用一种方式使读者不用停下来重读你的代码。当你对代码做改动时，从全新的角度审视它，把它作为一个整体来看待。（避免让原代码的控制流程易读性变差）
拆分超长的表达式
把你的超长表达式拆分成更容易理解的小块 要小心“智能”的小代码块——它们往往在以后会让别人读起来感 到困惑（条件判断中的短路逻辑有时会大大增加理解成本）
变量与可读性
让你的变量对尽量少的代码可见(因为人的思维栈也是有限的，过多变量在栈中存在是理解负担) 操作一个亦是的地方越多，越难确定它的当前值（尽量收拢变量的写逻辑，让它在更少的地方被改动）
确认这部分所说的 Bad Smell 的最好办法是，当你读到一个控制逻辑时，要反反复复地阅读，甚至用笔来记录时才能避免理解出错时，就意味着它需要修改了。具体如何修改，可以看书中的介绍
重新组织代码
抽取不相关的子问题
把一般代码和项目专有的代码分开
一次只做一件事
如果你有很难读的代码，尝试把它所做的所有任务列出来。其中一些任务可以很容易变成单独的函数（或类）。其他的可以简单地成为一个函数中的逻辑“段落”。
把想法变成代码
先用自然语言描述程序（debugging duck）
少写代码
最好读的代码就是没有代码（You aren't gonna need it, xp 的 YAGNI 原则） 从项目中消除不必要的功能，不过度设计 重新考虑需求，解决版本最简单的问题经常性通读标准库 API，保持对它们的熟悉程度
这部分设计函数级甚至类，需求分析级别的话题。在现实环境中，通常需求分析沟通是非“技术向”的事情。本部分“技术向”的部分是：让函数一次做且只做一件事，通过自然语言描述让代码逻辑更清晰，通常熟练掌握库 API ，避免重新发明轮子，字不必要的代码
精选话题
测试与可读性
测试应当具有可读性，以便其他程序员可以舒服地改变或增加测试 选择一组最简单的输入，让它能完整使用被测试代码 简单又能完成工作的测试值最好（测试代码中的输入或预期结果越简单越容易理解） 不能为可测而牺牲真实代码的可读性（而应对真实代码进行切实的改造，使之在有可读性的基础上可测）
这一部分读了可测性还有一章练习题可加深理解
附录：深入阅读
此部分介绍了一些经典书籍，去除一些和具体语言相关的，摘录如下，
《Code Complete》中译：代码大全
《Refactoring: Improving the Design of Existing Code》中译：重构：改进既有代码的设计
《The Practice of Programming》中译：程序设计实践
《The pragmatic Programmer: From Journeyman to Master》中译：程序员修炼之道：从小工到大师
《Clean Code: A Handbook of Agile Software Craftsmanship》中译：代码整洁之道
《Literate Programming》文学式编程
No comments:
Post a Comment