如何编写干净的代码

编写干净的代码就像写诗。诗歌易于理解，具有变革的力量，并且以简洁的方式写成。

干净的代码意味着一个可扩展的组织。这就是初级开发人员和高级工程师之间的区别。这意味着能够在没有太多混乱的情况下调整计划。

经过多次推荐，我才鼓起勇气读了《代码整洁之道》。它是那种让人忍不住要以貌取人的书。不过我承认，它确实名副其实。见解清晰、具体、实用，还带有一丝书呆子式的幽默，直击我的内心。今天，我和大家分享我的一些心得体会。

1. 代码的可读性和可执行性同样重要

软件项目的大部分成本都花在了长期维护上。因此，你编写的代码应该清晰地表达你的意图，以便新开发人员能够轻松理解正在发生的事情及其原因。代码编写者写得越清晰，其他人理解所需的时间就越少。这可以减少缺陷并降低维护成本。

• 如何做到这一点：良好的命名实践+单一职责类和函数+编写测试

2. 以后等于永远

说实话，我们都说过以后会回去清理，但最后却忘了。不要留下那些不再有用的无用代码。它们会让其他开发者感到困惑，而且没有任何价值。修改功能时，务必删除旧代码。无论如何，如果你在其他地方破坏了代码，测试应该会通知你。

• 如何操作：删除代码可能会让人感到害怕，尤其是在大型架构中。因此，测试是保持代码整洁的关键，这样你才能放心地删除代码。

3. 函数应该小

函数的首要规则是代码要小——不要超过20行。这是因为函数越小、越集中，就越容易选择一个描述性强的名称。

当谈到函数的参数时：理想的数量是 0。然后是 1，然后是 2，但应尽可能避免超过 3。

• 如何做到这一点：功能应该遵循单一职责原则和开放封闭原则。

4. 重复是所有代码的罪魁祸首

重复是精心设计的系统的敌人。它意味着额外的工作、额外的风险和额外的不必要的复杂性。

• 如何做到这一点：始终通过保持代码 DRY（不要重复）、隔离和模块化来避免这种情况。

5. 唯一好的评论是你找到办法不写的评论

“没有什么比恰到好处的评论更有帮助了。但评论充其量只是必要之恶。”

注释的正确使用是为了弥补我们在代码中表达自我的不足。注释总是失败的。我们必须使用它们，因为没有它们我们总是无法弄清楚如何表达自己，但使用它们并不值得庆贺。

问题是，注释经常会撒谎。并非总是如此，也不是故意的，但太频繁了。注释越旧，距离它所描述的代码越远，就越有可能完全错误。

原因很简单：程序员实际上无法维护所有注释，因此它们常常会脱离他们所描述的代码，成为准确性不断下降的孤立代码。注释通常只是糟糕代码的借口或借口，或是为不充分的决策辩解，无异于程序员的自言自语。

• 如何做到这一点：描述性命名实践，让开发人员知道变量代表什么+提供测试，以便其他开发人员可以看到主要功能是什么。

6. 对象暴露行为但不暴露数据

模块不应该了解它所操作的对象的内部结构。对象会隐藏数据并暴露操作。这意味着对象不应该暴露其内部结构，accessors因为这样做实际上是暴露而不是隐藏其内部结构。你没必要让每个人都看到你的裸体。

• 如何做到这一点：变量的范围应尽可能局部，但不要暴露过多的必要内容。

7. 关于测试

测试代码与生产代码同等重要，因此，它必须随着生产代码的演进而不断变化和发展。保持测试的整洁至关重要，因为没有测试，您将失去保持生产代码灵活性、可维护性和可重用性的关键。如果您进行了测试，您就不会害怕修改代码；而如果没有测试，每次修改都可能存在 bug。测试消除了清理代码会破坏代码的担忧。

可读性使测试保持简洁，因为它们提供了一个机会，可以用通俗易懂的语言向其他开发人员解释原作者的意图。因此，我们希望在每个测试函数中只测试一个概念，这样测试才更具描述性，更易于阅读，并且在测试失败时更容易跟踪。清晰的划分和良好的测试编写有助于明确预期，并保持范围清晰。

如何做到这一点：遵循 FIRST 原则：

• 快速：测试应该快速运行。如果每次测试都需要等待太长时间，你就不太可能经常运行它们。
• 独立/隔离：测试不应该相互依赖或相互构建。它们应该尽可能隔离。
• 可重复：测试应该在任何环境中都是可重复的——开发、准备或生产。
• 自我验证：测试应该有一个布尔输出。要么通过，要么失败。
• 彻底：测试应该涵盖所有边缘情况、所有安全问题、每个用例和快乐路径。

8. 关于错误处理和异常

抛出的每个异常都应提供足够的上下文来确定错误的来源和位置。虽然通常情况下，任何异常都会生成堆栈跟踪，但堆栈跟踪无法告知您失败操作的意图。

应尽可能避免在代码中传递 null。如果您希望从方法中返回 null，请考虑抛出异常。将错误处理设置为单独的关注点，使其独立于主逻辑之外。

• 如何操作：创建信息丰富的错误消息，并将其与异常一起传递。提及失败的操作以及失败的类型。我们最关心的是如何捕获它们。

9. 关于课程

类应该精简，但与其数代码行数，不如数职责。类名是描述其职责的关键。我们的系统应该由许多小类组成，而不是几个大类，每个小类都封装一个职责。每个类都有其存在的理由，并与其他几个类协作以实现所需的系统行为。

很少有充分的理由使用公共变量。放松封装永远是不得已而为之，实例变量的数量应该尽可能少。好的软件设计能够适应变化，而无需投入巨额资金和进行大量返工。缩小变量的作用域可以让我们更轻松地做到这一点。

• 如何做到这一点：关注点分离是我们设计领域最古老、最重要的技术之一。这是有原因的。相信它。类应该对扩展开放，但对修改关闭。在理想的系统中，我们通过扩展系统来引入新功能，而不是修改现有代码。

10. 关于格式

每个空白行都是一个视觉提示，用于标识一个新的独立概念。

局部变量应该出现在函数的顶部。

实例变量应该在类的顶部声明。

短行比长行更受欢迎——通常大约 45 个字符到 100-120 个字符。超过这个长度，可能就太粗心了。

• 如何操作：大多数选项都可以传递给 CI 或文本编辑器中的 linter。充分利用这些工具，让你的代码尽可能干净。

软件开发原则

总而言之，遵循这些做法，你的代码就会干净：

a) 命名变量：隐式地知道事物在哪里 - 并使用合适的命名等方法 - 对于保持代码的可读性和可维护性至关重要。

“您应该像为第一个孩子命名一样谨慎地命名变量。”

选择好名字最难的地方在于，它需要良好的描述能力和共同的文化背景。任何开发人员都能读懂并提升代码的简洁性。

变量、函数或类的名称应该能够解答所有重要的问题：它为什么存在、它的作用是什么以及如何使用。如果名称需要注释，那么它就无法正确展现其含义。程序员必须避免留下虚假的线索，以免掩盖代码的真正含义。

较长的名称优于较短的名称，任何可搜索的名称都比代码库中的常量更好。单字母名称只能用作短方法中的局部变量：名称的长度应与其作用域的大小相对应。方法应为动词或动词短语；类名不应为动词。

b) 最小化依赖：我们应该避免让太多代码了解第三方的细节。依赖你能控制的东西总比依赖你无法控制的东西要好。如果你依赖了，最终反而会被它控制。

c) 整洁：一段代码应该放在你期望找到它的地方。代码库应该直观易懂；开发者的意图应该清晰可见。

d) 清理：不要在代码中堆砌无用的代码片段，也不要用那些记录历史或未来愿景的代码行。减少重复，提高表达能力，并尽早构建简单的抽象。

e) 标准化：您的代码应该在各个存储库中保持一致的编码风格和实践。

f) 自律：你经常反思自己的工作，并愿意做出改变和改进。然而，你不会太快陷入炒作。深入而有目的地学习新的技术栈。

事实上，保持代码整洁是保持创新和组织活力的关键。随着系统规模的扩大和发展，旧的技术实践和技巧不可避免地会残留在代码中。保持代码库整洁不仅仅是为了其他开发者的友好姿态，更是长期生存的必要条件。代码越整洁，开发者就越开心，产品就越优秀，寿命也就越长。