>[success] # 表达原则 **代码的可读性差，没能很好地串联起代码内在的逻辑**,常见的 * 接手维护项目，却发现文档缺失、代码无注释，加上维护人离职，基本只能靠猜来梳理代码逻辑。 * 代码风格过于抽象（命名过短、魔鬼数字、重名方法等），看不懂，也不敢轻易修改。 * 运行代码出现故障时，不打日志，不抛异常，导致定位问题需要耗费很长时间。 * 大段的`if-else`代码嵌套组合，调用逻辑复杂冗长，扩展性差，重构优化费时、费力。 >[danger] ##### 提升代码可读性代码特点 1. **易于维护**，设计文档、需求文档和口头交流只能表达部分业务逻辑的意图。可读性高的代码，能让阅读者在阅读时快速理解编写者的意图 2. **易于重构**，代码的可读性太差在某种程度上决定了你重构意愿的大小 3. **易于测试**，可读性高的代码，参数与输出都更清晰，在测试时能更精准地找到对应逻辑和问题点 4. **易于应用设计模式**，好读懂代码跟方便理解分析出要使用较好的设计模式进行重构 >[danger] ##### 表达原则 表达原则（Program Intently and Expressively，简称 PIE），起源于敏捷编程，是指编程时应该有清晰的编程意图，并通过代码明确地表达出来，**代码即文档**，在开发代码时，**应该更注重代码表达的意图是否清晰** * **代码表现形式**：在命名（变量名、方法名、类名）、代码格式、注释等方面的改进,无论是变量名、类名还是方法名，好的名字能快速准确地传达要表达的含义，而缩写、自定义名称会让代码变得难以理解,命名的优化加上注释的说明让源代码的逻辑变得清晰起 * **控制流和逻辑**：尽量分离控制流和逻辑，让代码变得更容易理解,如果过多`if`嵌套无法保证逻辑简单清晰 * **惯性思维**：找出常犯的一些惯性思考方式并逐一改进，**要避免一次性代码**一次性代码一旦修改需要，多处就得跟着修改，而多次修改又可能会出现遗漏的风险，**要避免复制粘贴代码**复制代码往往都对内部逻辑不了解，等真正出现问题时候再去修改发现梳理逻辑更加困难， **避免写超长代码**，**避免过度简化命名和表达式**，**避免写是什么的注释**，代码的命名和结构如果能直接反映出来“是什么”的话，我们就不应该用注释去表达，因为看代码一眼就能明白，应该多写“为什么”的注释，比如，为什么要多加一个适配的方法，原因可能是线上 xxx 问题引起，或临时修复的Bug，后续可能随 xxx 接口调整而废弃，“为什么”的注释还有一个好处：尤其在早期快速迭代过程中，能给后来的维护者提供一个优化的切入点，而不至于交接代码后让维护代码的人看不懂、不敢动 **表达原则的核心思想在于：通过代码清晰地表达我们的真实意图**，虽然软件开发过程中会有诸多文档，比如，架构设计文档、流程文档、PRD 文档等，但这些文档并不足以帮助我们正确理解代码是如何运行和组织的，很多时候我们只能通过阅读代码来掌握软件的真实运行情况。 我们之所以应该把提高代码可读性作为第一要务，就是因为读代码的次数远比写代码的次数多