【读书笔记】编写可读代码的艺术
【摘要】 鲍斯维尔的经典著作《编写可读代码的艺术》的读书笔记、精华总结。
开始
好代码会明确告诉你他在做什么。使用它会很有趣，并且会鼓励你把自己的代码写得更好。代码应该写的容易理解，使别人用最短的时间理解你的代码。
代码应该易于理解
可读性基本定理：代码的写法应当使别人理解它所需的时间最小化。
尽管减少代码行数是一个好目标，但核心还是理解的时间最小化。这是更好的目标。
可读性不会与更有效率、易测试等目标有冲突，往往会把你的代码引入更好的架构以及易测试。
犹豫不决时，可读性基本定理总是优于其它原则。
把信息装进名字里
尽管空间不算大，选择一个好名字可以让它承载更多信息。
选择专业的词。（例如，不用Get，而用Fetch或者Download）
避免泛泛的名字（或者说要知道什么时候要使用它，例如tmp、retval，除非使用他们有特殊的理由）
用具体的名字代替抽象的名字。（ServerCanStart就不如CanListenOnPort清楚）
使用前缀或者后缀来给名字附带更多的信息。（例如在值为毫秒的变量后面加上_ms，或者在还需要转义的未处理的变量前加raw_）
决定名字的长度。（小的作用域里用短一点的名字；长名字已经不再是问题；适当缩写；丢掉无用的词）
利用名字的格式来表达含义。（有目的地使用大小写、下划线。例如可以在类成员和局部变量后面加上_来区分它们）
不会误解的名字
要取不要有二义性的名字，让人有误解，取名字前最好多吹毛求疵点，取没有二义性的好名字。
定义上限下限时max_和min_是很好的前缀。对于包含的范围，first和last是好的选择。对于包含/排除范围，begin和end是最好的选择，因为他们最常用。
当为布尔值命名时，使用is和has这样的词明确表示它是个布尔值；避免使用反义的词（例如disable_ssl）
小心用户对于特定词的期望。例如用户会期望get()或者size()方法是轻量级的。
审美
好的源代码应该看上去养眼。如何用好的留白、对其及顺序来让你的代码变得更易读。好的审美与好的设计师两种独立的思想，最好同时在两个方向上努力做好。原则：
使用一致的布局，让读者很快就习惯这种风格。
让相似的代码看上去相似
把相关的代码行分组，形成代码块。
好处：
使用从审美角度讲让人愉悦的代码更容易。
看上去漂亮的代码通常不限于表面层次的改进，还会帮你把代码的架构做得更好。
具体技巧：
如果多个代码块做相似的事情，尝试让他们有同样的剪影。
把代码按“列”对其可以让代码更容易浏览。
如果一段代码中提到A、B和C，那么不要在另一段中说B、C和A。选择一个有意义的顺序，并始终使用这样的顺序。
用空行把大块代码分成逻辑上的段落。
该写什么样的注释（什么地方写注释）
注释的目的是尽量帮助读者了解的和作者一样多。
什么时候不写注释？（不要为那些从代码本身就能快速推断的事实写注释；不要给不好的名字加注释，应该把名字改好）
很多好的注释，仅通过记录你的想法就能得到，写代码时有过的重要想法。（加入导演评论、描述瑕疵、给常量加注释）
站在读者的立场上思考（预料代码中那些部分会让读者有疑问，注释之；意料之外的陷阱加注释；文件、类级别添加全局观类注释；代码块添加总结性注释）
克服作者阻滞心理
不管心理想什么，先把它写下来。
对一下这段注释，看看有没有地方可以改进。
不断改进。
写出言简意赅的注释
注释最好要写得精确、细致、紧凑、高信息/空间率。
具体技巧：
像it和this这样的代词可能会指代多个事物时避免使用。
尽量精确描述函数的行为。
在注释中用精心挑选的输入输出例子进行说明。
生命代码的高层意图，而非明显的细节。
用嵌入式注释解释难以理解的函数参数。
用含义丰富的词来使注释简洁。
把控制流变得易读
把条件、循环以及其它控制流的改变做得越自然越好。运用一种方式使读者不用停下来重读你的代码。
在写一个比较时，把改变的值放在左边，更稳定的放在右边。if else优先处理正确、简单、有趣的情况。
三目、do while、goto导致代码变差，最好不要用。
把嵌套式的难理解的改写为线性的代码。
提早返回会让代码更整洁。
拆分超长的表达式
引用解释变量：把巨大的表达式拆成小段；通过用简单的名字描述子表达式让代码文档化；帮助读者识别代码中的主要概念。
使用摩根定理来操作逻辑表达式把布尔表达式用更整洁的方式重写。
变量与可读性
变量的问题：
变量越多，越难全部跟踪他们的动向。
变量的作用域越大，就需要跟踪它的动向越久。
变量改变越频繁，就越难以跟踪它的当前位置。
方法：
减少变量，消除中间结果变量。
减少变量的作用域。
最好使用只写一次的变量（常量）
抽取不相关的子问题
把一般代码与项目专有代码分开。结果是，大部分代码都是一般代码。通过建立组库和辅助函数来解决一般问题，剩下的只是让你的程序与众不同的核心部分。
对于子问题的解决方案更倾向于更加完整和正确。可以在后面重用它们。
把一个方法中所有操作保持在一个抽象层次上。
一次只做一件事
如果有很难读的代码，尝试把他们分解成若干个小任务，其中一些很容易变成单独的函数，其它的可以简单的成为一个函数中的逻辑段落。比较难的是如何准确识别、描述、区分它们。
把想法变成代码
如果你不能把一件事给你奶奶讲清楚的话，就说明你没真正理解。
能够把一个想法精炼，排除会迷惑干扰人的细节，用自然语言向别人描述解释清楚，是很重要的能力。你也理解的深刻了。把你的代码展示给别人看是一样的道理。
过程：
像对着一个同事一样用自然语言描述代码要做什么。
注意描述中所用的关键词和短语。
写出与描述匹配的代码。
少写代码
最好读的代码就是没有代码。要有知道什么时候不用写代码的能力，通过重用库函数或者减少功能来少写代码。
方法：
从项目中消除不必要的功能，不要过度设计。
重新考虑需求，解决版本最简单的问题，只要能完成工作就行。
经常通读标准库的API，保持对库函数选用的敏感度。
使测试易于阅读和维护
测试代码应当具有良好的可读性，方便维护测试代码以及理解功能代码。
改进方法：
每个测试的最上一层越简明越好，输入输出最好可以用一行代码描述。
如果测试失败了，错误消息应该容易跟踪并辅助修复bug。
使用最简单的并且可以完整运用代码的测试输入。
测试函数取完整描述性的名字，以使每个测试所测到的东西明确。
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）