故小里做开发这几年，我改过不少团队的代码，也被人改过代码。最扎心的事不是需求变来变去，而是接手一段自己上周写的代码，读了三遍还没看明白。很多时候，一段代码能不能跑起来只是及格线，能不能让下一个读代码的人快速看懂、放心修改，才是真正的分水岭。这篇分享的50个让代码更优雅的小技巧，就是我从日常开发、代码评审和一堆“事后补救”里攒出来的避繁就简经验，覆盖命名、函数设计、控制流、语言特性、异常处理、性能、编辑器习惯和重构思路，适合刚入行的开发者，也适合写业务代码写到想重构的老兵。
1. 为什么避繁就简：优雅代码的底层逻辑
先说一个有点反直觉的事：优雅的代码，写起来通常不炫技，反而看起来很“怂”，不追求一行写出天际，只追求别人接手时不用猜。你去看那些成熟的开源项目，多数核心代码都是平铺直叙的，直白到让你觉得“这我也能写”。但真到自己写，就总忍不住加一层抽象、套一个设计模式、顺手再造一个轮子。所以聊技巧之前，先立四条规矩，后面所有招式都从这里长出来。
1.1 先立规矩：四条原则，招式才有意义
技巧1：最小惊讶原则。代码的行为要符合绝大多数人的直觉。一个函数名叫 get_user，就别在里面偷偷改数据库；一个方法返回 None 表示失败，就别偶发抛异常。使用者越是能猜到你的意图，代码就越不容易被误用。
技巧2：KISS，保持简单。能用 if 讲清楚的事，不要硬上策略模式；能用一个函数解决的事，不要搭一个三层继承体系。简单不是简陋，而是每个组件只承担一个明确职责，删掉任何一个都不影响整体跑通。
技巧3：DRY，别重复自己。复制粘贴一时爽，维护起来火葬场。同一段逻辑在三个地方出现，将来改需求的时候大概率只改两处，第三处就成了隐藏炸弹。
技巧4：YAGNI，你现在不需要它。不要为了“以后可能会用到”去预留抽象接口、配置开关、扩展点。没有真实需求支撑的抽象，最后都会变成没人敢动的死代码。
这四条原则不是口号，是后面每个技巧的“裁判”。遇到拿不准的方案，就用它们过一遍：这个做法会不会让人意外？有没有更简单的写法？是不是重复了？是不是提前造了不需要的东西？四个问题问完，答案基本就浮出来了。
1.2 50个技巧怎么分布
后面六个章节按“代码从写到维护”的顺序展开：先讲命名和格式，这是代码给人的第一印象；再讲函数和控制流，这是主逻辑的骨架；然后是利用语言特性和标准库，用更少的代码表达更准确的意思；接着是异常处理、性能优化、工具链协作，最后落到重构和清理。每一节里的技巧都会配上实际代码片段和我在项目里踩过的坑，你可以直接照着改。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 命名、注释与格式：代码的第一印象
代码写出来是给人看的，顺便给机器执行。既然人是第一读者，那命名和格式就是阅读体验的起点。很多同学觉得命名浪费时间，其实一个贴切的名字能省下至少三条注释，一个糟糕的名字能制造至少三次误会。这一节是性价比最高的优化区。
2.1 命名：让名字自己会说话（技巧5-7）
技巧5：变量名要表达意图，不要用通用词糊弄人。data、temp、list、flag 这类名字，除了告诉你“这里有个东西”之外什么也没说。我见过一段处理订单的代码，变量叫 data1、data2、data3，三个人接手，每个人的理解都不一样。改成 pending_orders、paid_orders、refunded_orders 之后，逻辑瞬间就清晰了，甚至不用看注释。
技巧6：布尔变量用 is、has、can 开头，让条件读起来像自然语言。比如 is_ready、has_permission、can_retry，在 if 条件里连起来就是一句完整的话：if user.has_permission and order.can_retry: 不需要额外注释，语义自己会说话。反过来，一个叫 status 的布尔值就很容易让人困惑，到底 True 代表成功还是失败？没人敢确定。
技巧7：函数名用动词开头，表明这是动作。get_user_name()、send_notification()、calculate_total_price() 一看就知道在干什么。如果你写的函数名是名词，比如 user_name()，读代码的人就得去翻函数体，才知道这是取值还是赋值。动词开头是给函数贴“动作标签”，也是让调用点变成可读语句的快捷方式。
2.2 注释、常量与文件组织：减少视觉噪音（技巧8-11）
技巧8：注释解释“为什么”，不要复述“是什么”。 i += 1 // i加1 这种注释等于没写，因为代码本身就表达了这层意思。值得写注释的是那些“看起来奇怪但必须这样”的决策，比如：为什么要等三秒再重试？为什么不直接用现成库？为什么这里要单独处理空指针？这类背景信息代码表达不了，只有注释能留住。写注释的时候，想象你是给一个月后的自己留口信，而不是在给代码写说明书。
技巧9：魔法数字和魔法字符串要提升为具名常量。代码里直接写 if retry_count > 3，大家会问这个3是啥意思；写成 if retry_count > MAX_RETRY_TIMES，语义就清楚了。字符串也一样，散落的 "paid" 状态值，一旦拼错一个字母，排查起来非常痛苦。把这些值收敛到常量或枚举里，改一处全局生效，也不会出现“同一个状态有三种写法”的尴尬。
技巧10：整个项目要统一一种命名风格。Python 用 snake_case，Java 和 JavaScript 用 camelCase，常量用全大写。单个文件风格统一容易，难的是整个仓库统一。这个只能靠团队约定和自动化检查兜底，比如 ESLint、Pylint 里配置命名规则，不合规范直接报错，省得评审时为了下划线吵半天。
技巧11：文件、模块和类的命名也要有规律。一个文件只放一个核心类或一组高内聚函数，文件名和内部主类名保持一致。Python 模块用小写下划线，Java 类用大驼峰，目录结构按功能域而不是按技术类型划分。我从“按类型建目录”改成“按业务模块建目录”之后，找代码