团队编码标准不是摆设，是让代码能被别人看懂的底线

上周帮同事修一个线上 bug，打开他写的 Python 脚本，满屏是 def a():、def b():，变量名全是 tmp、res1、data_x。查到第三层嵌套函数时，我默默点了右上角关闭按钮——不是不想修，是真不敢动。

写得快，不如改得快

很多团队把“团队编码标准”当成入职培训里一页 PPT，念完就存档。结果呢？新来的同学照着老代码抄，老同学懒得改旧逻辑，三年下来，项目里 Python 和 Java 风格混用，缩进有空格有 tab，JSON 字段一会儿驼峰一会儿下划线。这不是技术债，是沟通债。

几条实在的落地建议

不必一上来就搞百页规范文档。先从三件事开始：

1. 统一命名规则
函数名用动词开头：calculate_total_price()，别写 getPrice()；布尔变量加 is_ 或 has_ 前缀：is_valid_email，而不是 valid_email（后者读起来像“这是个有效邮箱”，实际是个真假判断）。

2. 拒绝魔法数字和字符串
把 if status == 3: 改成 if status == ORDER_PAID:，并在顶部定义常量：

ORDER_PENDING = 1
ORDER_PAID = 3
ORDER_CANCELLED = 5

3. 提交信息不写“fix bug”
改成“修复订单导出时 CSV 中中文乱码：将 open() 的 encoding 参数从 'ascii' 改为 'utf-8-sig'”。别人一眼知道改了啥、为啥改、影响范围在哪。

标准不是用来罚人的

有团队把编码规范做成检查清单，CI 流水线卡住 PR 就算完事。但真正起作用的，是每天 Code Review 时顺手指出：“这个函数超过 20 行了，拆一下？”“这个 if 嵌套三层，提个 extract method 吧？”——语气轻松，但动作不松懈。

标准不是限制发挥，而是减少无谓消耗。当大家不用花十分钟猜某个 process_xxx_v2 函数到底干了什么，才能把精力真正放在解决业务问题上。

你团队的命名规范第一条写的是什么？评论区聊聊。