代码优雅之道：50个提升可读性与质量的实用技巧

“代码优雅”这四个字，你刚入行那阵可能会觉得虚，但等你接手过一个写满 a、b、tmp 的旧项目，或者在别人五百行的 longMethod 里翻过半天 bug，你就明白它有多重要了。代码表面上是写给机器执行的，实际上真正的读者是看代码的人，包括三个月后的你自己。这篇文章整理了 50 个让代码更优雅的小技巧，覆盖命名、函数、条件、错误处理、数据结构、性能、注释和工具链，基本都是动手写代码时能直接落地的习惯。适合刚工作的新人，也适合写了好几年代码、想回头收拾自己烂摊子的老手。不用一次性全记住，挑几条放进自己的代码里，效果马上就能看到。

1. 命名：代码的第一张脸，也是最低成本的优化

命名是投入产出比最高的代码改进方式。你不需要懂任何高深理论，只需要在每次给变量、函数、类起名字的时候多花十秒钟想一下，后面节省的时间按小时算。我见过太多代码变量叫 a、bb、tmp，函数叫 doIt、handleThing，写的时候很爽，两周后回来看，谁都不认识。命名的核心只有一条：让读到名字的人不看上下文就知道它在说什么。

1.1 变量命名：让名字自己说话

变量名是代码里出现频率最高的东西，也最容易被敷衍。很多新手觉得变量名随便起无所谓，反正值才是关键。这是最大的错觉。变量名的好坏，直接决定这段代码能不能被快速理解。这里的“别人”，很大程度上就是两周后的你自己。

01. 变量名写业务含义，不要写缩写和类型。
比如一组学生年龄，不要叫 l、list1、intArr，直接叫 student_ages。单个字母 l 和数字 1 还容易混淆，写的时候顺手，看的时候就想骂人。另一个例子是存用户名的字段，不要写 un，写 username；存邮箱的不要写 em，写 email_address。

python复制# 不好
l = [18, 20, 22]
# 好
student_ages = [18, 20, 22]

02. 布尔变量用 is/has/can 这类前缀开头。
布尔值是代码里语义最轻、也最容易被误解的变量。is_active、has_permission、can_edit，一眼就知道这是条件判断。不要写 flag = True，这个 flag 到底表示什么？没人知道。也不要写 status = 1 这种数字状态码，一个 status 带上一个魔法数字 1，读代码的人还得去查枚举定义。

python复制# 不好
flag = True
# 好
is_active = True
can_edit = False

03. 缩写要克制。
id、url、http 这种通用的缩写可以用，但 usrNm、cfg、pwd 这种随意缩的要避免。代码不是加密文，没必要为了省几个字符增加阅读成本。比如 password 就写 password，config 就写 config，清晰比短重要得多。我唯一允许短缩写的场景，是 for 循环里的循环变量 i、j、k，它们的作用域只有三五行，不会造成理解负担。

04. 不用 data、info、temp 这类万能模糊词。
data 到底是什么数据？info 是哪方面的信息？temp 为什么存在？这类名字等于把理解成本全部甩给读者。除非在写非常临时的代码，否则尽量避免。我一般允许 tmp 只出现在三行以内的交换变量场景里，再长就不行了。如果你发现自己在变量名里写 data2、final_data、data_final，说明这个变量的职责还没理清。

注意：命名这件事，不要为了“看起来短”牺牲“读起来懂”。该长就用完整单词，比如 password 不要写成 pwd，除非这是整个项目的统一约定。

1.2 函数与类的命名：动词宾语是个通用公式

函数和类名比变量级别更高，因为粒度更大，一旦乱了，代码骨架就歪了。函数命名建议遵循一条公式：动词加宾语，让人一看就知道这个函数做了什么事。我最怕看到 handle、process、do 这种万能动词，它们基本等于“我也说不清自己在干嘛”。

05. 函数名用动词开头的动宾结构。
get_user_by_id、update_avatar、send_notification，都比 handle_user、do_thing 清楚得多。动词也要准确，get 表示查询，update 表示修改，send 表示发送。用词准确了，函数内部做什么，调用方基本能猜到一半。

python复制# 不好
def handle(user):
    ...

# 好
def get_user_by_id(user_id):
    ...

06. 类名用名词，接口名用能力词。
UserRepository、PaymentService 是名词，表示一类对象；EmailSender 是能力，表示它能发邮件。别把类名起成动词，比如 Login 不是一个类，LoginSession 才是。接口名同理，尽量用一个能表示能力的名词或形容词，让读者一看就知道实现方承诺了什么行为。

07. 多用业务领域的词汇，让代码靠近需求文档。
业务里叫“逾期”，代码变量就叫 is_overdue，不要写 check_day_gt_today。前者读一遍就懂，后者还得算一下今天是不是大于到期日。代码和需求用同一套词汇，跟产品经理沟通的时候也会顺畅很多。这个习惯在业务系统里价值极高，因为大部分代码就是在翻译业务规则。

08. 一致性比某一次选得更“高级”更重要。
团队里如果有人用 get，你就跟着用 get，不要再用 fetch、retrieve 混着来。统一词汇表的价值，在于整个代码库形成一种可预测的节奏，读起来顺滑。这个优先级，高于