“把 if 往上提，for 往下放！”

转载于 2025-06-18 10:04:29 发布 · 54 阅读

CC 4.0 BY-SA版权

原文链接：https://mp.weixin.qq.com/s?__biz=MzA5NzgzODI5NA==&mid=2454103231&idx=2&sn=0c1d30d7db8a8ca049c05678fd2d6c39&chksm=86ac8484b40d2a6941438120d773e2a504a9e5c9b611087a52bacb802977f41730a152a32bb9&scene=126&sessionid=0

本文经授权转自公众号优快云（ID：优快云news）

作者 | Alex Kladov，翻译 | 苏宓

很多程序员写代码的时候都会遇到这种情况：一个判断条件到底该放在函数里面还是外面？循环里是不是可以加个 if？这些看起来无关紧要的小选择，实际会影响代码的清晰度、性能。最近，一位热爱简单代码和编程语言的程序员 Alex Kladov 在博客上分享了两条简单但特别实用的经验法则，引发不少开发者的注意。其表示：“把 if 往上提，把 for 往下放（Push Ifs Up, Push Fors Down）”。这会对提升代码质量有哪些作用，我们不妨通过本文一起来看看。

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

1、把 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)  }}

2、把 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 循环往下推！

本文转自公众号“优快云”，ID：优快云news

---END---