可读代码的艺术
内容提要
《可读代码的艺术》强调代码可读性以快速理解为标准，需平衡简洁与可读。变量名应精准描述信息，避免tmp等通用词和歧义。代码美学要求统一格式、固定顺序、分块注释。注释应解释意图而非重复代码，记录想法与瑕疵。简化逻辑可用提早返回、最小化嵌套、拆分表达式。变量应缩减作用域、用时声明。代码结构上抽离子问题、每次做一件事，像写大白话一样写代码，并尽量减少代码量。
延伸解读
可读性优先：平衡简洁与理解成本
文章指出，可读性的标准是看懂代码所需时间越短越好，这关系到修改、添加功能和调试的效率。代码并非越短越好，需要在可读性和简约之间找到平衡。即使为了性能使用“忍者代码”，也必须在注释中写清含义。作者强调，大多数时候存在兼顾可读性、性能和结构的方案，而最难的是时刻注意自己写的代码是否好读。
命名与注释：精准传达意图
变量名应精准描述信息，避免使用 tmp、retval 等通用词，并注意减少歧义，例如 filter 可能被理解为“过滤掉”或“过滤得到”，建议改用 select 或 exclude。注释应解释意图而非重复代码，记录想法、瑕疵和常量设定原因。如果变量名或方法名已能说明问题，再加注释反而多余，此时应优先改进命名。
简化逻辑与结构的实用技巧
文章推荐用提早返回、最小化嵌套、拆分大型表达式来简化逻辑。例如，将嵌套的 if 改为多个提早返回，能降低思维负担。对于变量，应缩减作用域、用时再声明，并考虑删除暂时变量和中间变量。在代码结构上，抽离子问题、每次做一件事，像写大白话一样写代码，有助于发现逻辑问题并提升可读性。
减少代码量：最可读的代码是没有代码
文章强调“最可读的代码就是没有代码”，建议去除无意义的 feature、避免过度开发、了解语言内置接口以避免重复造轮子，并寻找靠谱的开源库。这些做法不仅能减少代码量，还能降低维护成本。作者最后推荐了《Code Complete》《Refactoring》等拓展阅读，供读者深入学习。
Q&A
《可读代码的艺术》中，可读性的标准是什么？
可读性的标准是能看懂，即能够改功能、加功能、debug，看懂所需时间越短越好。代码并不是越短越好，要衡量好可读性和简约的平衡。
如何给变量命名以提高代码可读性？
变量名应精准描述信息，避免使用 tmp、retval 等通用词，避免歧义。例如，用 Fetch 或 Download 代替 Get，用 delay_secs 代替 delay。不同命名形式代表不同变量类别，如 const 全大写，类用帕斯卡，普通变量用驼峰。
在代码美学方面，有哪些具体要求？
代码美学要求统一格式、固定顺序、用回车和注释将代码划分成块。同一类代码保持相同的外形，例如对齐相似的代码块。
注释应该怎么写？有哪些雷区？
注释应解释意图而非重复代码，记录想法与瑕疵。雷区包括：如果变量名或方法名能看明白，再加注释就是反效果；不要为了注释而注释。应优先修改变量名而不是加注释。
如何简化代码逻辑？
简化逻辑可用提早返回、最小化嵌套、拆分表达式。例如，把肯定情况放在前面，用三元运算符代替简单 if-else，使用德摩根定律简化表达式。
如何管理变量的作用域和声明？
变量应缩减作用域、用时声明。删除没用的变量，如暂时变量和中间变量。在最接近使用位置声明变量，使用常量减少变量赋值次数。
如何组织代码结构以提高可读性？
抽离子问题，每次做一件事。像写大白话一样写代码，用人类语言描述过程，然后转化为代码。例如，将投票变化逻辑拆分为减去旧票和加上新票。
如何减少代码量？
去除无意义 feature，不要过度开发。了解你的语言有什么接口，接口能实现的事情就不要自己写了。寻找其他靠谱的开源库。
