“把 if 往上提，for 往下放!”（在if-else语句中,当条件成立时,就执行什么后的语句组）

关于两条相关经验法则的简短说明。

把 If 条件往上推

如果函数内部有 if 条件判断，可以考虑是否能把它移到调用者那里：

// 好的写法fn frobnicate(walrus: Walrus) { ...}// 不好的写法fn frobnicate(walrus: Option<Walrus>) { let walrus = match walrus { Some(it) => it, None => return, }; ...}

就像上面举的例子一样，函数里经常会有“前置条件”的检查——比如你传进来的参数是不是有效、是不是空之类的。很多时候，程序员会在函数内部去检查这些情况，如果不符合就什么都不做。但更好的做法，其实是把这些判断提前，在调用这个函数之前就处理好。这样一来，函数本身就可以更专注地完成它的核心工作，不用管太多额外的事。

为什么要这么做？有两个原因：

首先，如果每个函数都自己检查一次条件，那整个程序里可能会有很多重复判断，既费事又容易出错。把判断提前处理好，可以让代码整体更简洁高效。

其次，if 语句（也就是“如果……就……”）本身就是让程序变复杂的东西。判断多了，程序流程就绕了，Bug 也容易藏在里面。所以与其到处乱插 if，不如集中放在一个地方处理——比如放在主函数里统一决定怎么走，然后把具体的执行任务交给其他小函数去做，这样结构更清晰，出错的概率也更低。

而且，如果所有的判断都集中在一个地方，程序员在看代码的时候也能更容易发现有没有重复判断，或者根本不会被执行的“死代码”。比如：

fn f() { if foo && bar { if foo { } else { } }}fn g() { if foo && bar { h() }}fn h() { if foo { } else { }}

对于 f() 来说，更容易看出无用分支，而分散在 g() 和 h() 的组合里不容易发现。

这里还有一个相关的模式，叫做“dissolving enum”重构。有时候代码会长这样：

enum E { Foo(i32), Bar(String),}fn main() { let e = f(); g(e)}fn f() -> E { if condition { E::Foo(x) } else { E::Bar(y) }}fn g(e: E) { match e { E::Foo(x) => foo(x), E::Bar(y) => bar(y) }}

这里有两处分支，通过往上提，可以发现它们其实是同一个条件被重复了三次（第三次变成了数据结构）：

fn main() { if condition { foo(x) } else { bar(y) }}

把 For 循环往下推

这条建议来自“面向数据”的编程思想。简单说就是：少就是少，多就是多。现实中的程序，大多数时候都不是在处理一个东西，而是一大批东西。特别是在那些对性能要求高的关键部分（也叫“热点路径”），几乎总是在同时处理很多个对象——正是因为数量多，这部分代码才会“热”。

所以，一个常见的好习惯是：从一开始就把“批量处理”当成主要方式，而不是只想着一个个地处理。如果真的需要处理单个对象，那就把它当成“批量里的一个特例”来对待。这样做，不光能让程序结构更清晰，还能为后面提升性能打下基础。比如：

// 好的写法frobnicate_batch(walruses)// 不好的写法for walrus in walruses { frobnicate(walrus)}

这样做最主要的好处是性能，尤其在极端情况下非常明显。

如果有一整批数据可以一起处理，就能摊销启动成本，还能灵活调整处理顺序。实际上，你甚至不必按特定顺序处理实体，可以先对所有实体的某个字段统一处理，再处理其他字段，利用向量化或结构化数组技巧。

一个有趣的例子是基于 FFT 的多项式乘法：在一堆点上同时计算多项式，比一个点一个点计算要快得多！

如果 if 往上推，for 循环往下推，两条规则还能组合使用：

// 好的写法if condition { for walrus in walruses { walrus.frobnicate() }} else { for walrus in walruses { walrus.transmogrify() }}// 不好的写法for walrus in walruses { if condition { walrus.frobnicate() } else { walrus.transmogrify() }}

好的写法避免了在循环内部反复判断条件，减少了循环里的分支，提高了性能，甚至可能解锁向量化优化。

这个模式既适用于微观层面，也适用于宏观架构层面，比如 TigerBeetle 的数据平面就是对批量对象操作，以摊销控制平面决策的成本。

虽然性能是“for 循环往下推”的主要动机，但它也能提升表达力。比如早期很成功的 jQuery 就是针对元素集合的操作，抽象向量空间的语言思维往往比逐个坐标方程更清晰。

最后用一句话总结：把 if 条件往上推，把 for 循环往下推！

时间：2025 年 8 月 15–16 日

地点：北京·威斯汀酒店

2025 全球产品经理技术大会将汇聚互联网大厂、AI 创业公司、ToB/ToC 实战一线的产品人，围绕产品设计、用户体验、增长运营、智能落地等核心议题，展开 12 大专题分享，洞察趋势、拆解路径、对话未来。