代码整洁之道
[toc]
第一章
- 开篇第一句话我认为最符合本书主题：“阅读本书有两种原因：第一，你是一个程序员；第二，你想成为更好的程序员。”
- “勒布朗法则：稍后等于永不（Later equals never）”。 这句话在我的印象里确实说过 ‘：先这样吧，以后有时间在弄’，然后以后可能在也没弄过了。
第二章
- “变量、函数或类的名称应该已经答复了所有的大问题。它该告诉你，它为什么会存在，它做什么事，应该怎么用。如果名称需要注释来补充，那就不算是名副其实。” 也就是说，应该使用有意义的名称（驼峰命名法）来 ‘描述’ 它们。
- 做有意义的区分，如果有一个
productInfo和productData的类，虽然他们名字不同，但是表示的意思确无区别。 - 类名和对象名应该是名词或名词短语，例如：Customer、 WikiPage、Account 或 AddressParser。应该避免使用 Manager、Processor 、 Data 或 Info 这样的类名。类名不应当是动词。
- 方法名应当是动词或动词短语，如 postPayMent 、 deletePage 或 save 。
- 给每个抽象概念选一个词，并且一以贯之。例如，使用 fetch 、 retrieve 和 get 来给多个类中的同种方法命名。
- 避免将同一单词用于不同目的。
- 代码作者应尽力写出易于理解的代码。应该把代码写的一目了然，而不必让别人禅精竭虑的研究。
第三章
- 函数的第一条规则就是要短小。第二条规则是还要更短小。
- “函数应该做一件事。做好这件事。只做这一件事。” 做好函数拆分非常重要，不仅结构清晰，而且利于函数复用。
- 不要害怕长名称。长而具有描述性的名称，要比短而令人费解的名称好。长而具有描述性的名称，要比描述性的长注释好。
- 最理想的函数数量是 0 个，其次是 1 个，再次是 2 个，应该尽量避免 3 个参数。
- 最好把 try / catch 代码块的主体部分抽离出来，另外形成函数。
第四章
- 什么也比不上放置良好的注释来得有用。什么也不会比乱七八糟的注释更有本事搞乱一个模块。什么也不会比陈旧、提供错误信息的注释更有破坏性。
- 有些注释掉的代码，其实可以都删掉。
- 总的来说，就是只写必要的注释，能够清晰描述的注释。
第五章
- 合理的使用空白行分隔代码，能够使代码结构更加清晰，可读性大大增强。
- 在赋值操作符 “=” 的两侧加空格，以达到强调的目的。
let a = 1 - 不需要在函数名和左元括号之间加空格，因为函数和其参数密切相关，如果隔开，就显得互无关系。
- 函数中的参数需要用逗号隔开，表示参数是互相分离的。
- 乘法 “*” 之间没加空格，因为乘法具有较高的优先级。 加法和减法之间需要加空格，因为加法和减法的优先级较低。
第七章
我们可以使用 try/catch/finally 来捕获错误和抛出错误。
抛出的每个异常，都应当提供足够的环境说明，以判断错误信息的来源和位置。同时应创建信息充分的错误消息，并和异常一起传递出去，在消息中，应包括失败的操作和失败的类型。
第八章
- “如果有良好的软件设计，则无须巨大投入和重写即可进行修改”。 这就表示期初项目设计封装的重要性。
- 单元测试能够让你的代码可扩展、可维护和可复用。因为有了测试，就不用担心对代码的修改。没有测试，每次修改都有可能带来缺陷。
- 一个测试一个断言。或者可以说，单个测试中的断言数量应该最小化。
- 整洁的测试包含以下 5 条规则：
- 快速。测试应该够快，能够快速运行。
- 独立。每个测试应该相互独立。
- 可重复。测试应当可以在任何环境中重复使用。
- 自足验证。测试应当有布尔值输出。
- 及时。测试应当及时编写。
第十二章
- 只要遵循以下规则，设计就能变得“简单”：
- 运行所有测试
- 不可重复
- 表达了程序员的意图
- 尽可能减少类和方法的数量
- 有了测试，就能保持代码的整洁，方法就是递增式地重构代码。测试消除了对清理代码就会破坏代码的恐惧。
第十四章
- “编程是一种技艺甚于科学的东西。要编写整洁代码，必须先写肮脏的代码，然后再清理它。”
- “就像写作文一样，应该先写草稿，在写二稿，一次又一次地撰稿，最后写出终稿。写出好作文是一个逐步改进的过程。”
- “多数新手程序员没有特别认真地遵守这个建议。他们相信，首要任务是写出能工作的程序。只要程序能工作，就转移到下一个任务上，而那个能工作的程序就留在了最后那个所谓能工作的转态。多数有经验的程序员都知道，这是一种自毁行为。”